qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/9] main-loop: refactor qemu_system_shutdown_re


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH 4/9] main-loop: refactor qemu_system_shutdown_request()
Date: Wed, 20 Feb 2013 16:53:37 +0000
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Wed, 20 Feb 2013, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> writes:
> 
> > Il 20/02/2013 16:32, Anthony Liguori ha scritto:
> >> +    if (no_shutdown) {
> >> +        vm_stop(RUN_STATE_SHUTDOWN);
> >> +    } else {
> >> +        main_loop_quit();
> >> +    }
> >
> > Would it make sense to call vm_stop() unconditionally?  Then Xen can
> > just use the vmstate_change handler as a hook.
> >
> > Similarly, for reset it can just use qemu_register_reset.
> 
> Yeah, that's probably doable.
> 
> But can't we just factor out the destroy_hvm_domain(false); to be called
> after the main loop exits?  We could even add a machine finalize hook
> for this purpose.  Likewise, destroy_hvm_domain(true) could be called
> through a machine-specific reset handler.
> 
> Stefano, does this make sense?  I can do a quick but I'm not really
> setup to test it.

Reading the code and the comment in cpu_handle_ioreq:

/*
 * We do this before we send the response so that the tools
 * have the opportunity to pick up on the reset before the
 * guest resumes and does a hlt with interrupts disabled which
 * causes Xen to powerdown the domain.
 */

it seems to me that the difficult case is reset: if the guest requests a
machine reboot (for example via hw/piix_pci.c:rcr_write), according to
the comment QEMU needs to call destroy_hvm_domain(true) before notifying
the hypervisor that it is done with the IO request. The notification is
done by xc_evtchn_notify at the end of cpu_handle_ioreq.

One possibility would be to move the "IO request done" notification at
the end of the main loop, after the other bottom halves.
Of course we need to keep in mind that in the normal case (no shutdown,
no reset), xc_evtchn_notify still needs to be called before the next
cpu_handle_ioreq.

Another possibility would be to introduce a reset and a shutdown
notification chain, so that different QEMU sub-components can be
notified immediately when the guest issues a reset or a shutdown
request.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]