Re: Reset problem vs. MMIO emulation, hypercalls, etc...

[Avi Kivity <avi@redhat.com>]

On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
> 
>> See kvm_arch_process_async_events() call to qemu_system_reset_request()
>> in target-i386/kvm.c.
>> 
>> The whole thing is fragile, though: we rely on the order events
>> are processed inside KVM_RUN, in x86:
>> 
>> 1) If there is pending MMIO, process it.
>> 2) If not, return with -EINTR (and KVM_EXIT_INTR) in case
>> there is a signal pending.
>> 
>> That way, the vcpu will not process the stop event from the main loop
>> (ie not exit from the kvm_cpu_exec() loop), until MMIO is finished.
> 
> Right, it is fragile, thankfully we appear to adhere to the same
> ordering on powerpc so far :-)
> 
> So we'll need to test but it looks like we might be able to fix our
> problem without a kernel or API change, just by changing qemu to
> do the same exit_request trick for our reboot hypercall.
> 
> Long run however, I wonder whether we should consider an explicit ioctl
> to complete those pending operations instead...

It's pointless.  We have to support the old method forever.  There's no
material different between sigqueue() + KVM_RUN and KVM_COMPLETE, or a
KVM_RUN with a flag that tells it to exit immediately.

-- 
error compiling committee.c: too many arguments to function