|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH 2/7] Replace VMSTOP macros with a proper QemuState type |
Date: | Mon, 08 Aug 2011 17:27:24 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 |
On 08/08/2011 05:06 PM, Luiz Capitulino wrote:
> > This is why I suggested a reference count. In this case, we can always > stop the guest "twice", because we don't lost information when we resume. I could give it a try in the near future, as I really think it's independent from this series, but I still don't understand what can stop an already stopped VM besides the user. This is a real question, is it really possible? If only the user can do that, then the refcount is overkill as just returning an error will do it.
Most of the reasons in QemuState are asynchronous and can happen at any time while the guest is running. Because they're asynchronous, they can trigger before a monitor stop is issued but caught after it is processed.
We could possibly synchronize during user stop, but that lets us capture only the first non-user reason.
And even if we return an error, that only pushes the refcounting to the user; you probably don't want to return a "vm is already stopped" error to the user, he'll just ask "why are you telling me that".
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |