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
