qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] hw/qxl: inject interrupts in any state


From: Alon Levy
Subject: Re: [Qemu-devel] [RFC] hw/qxl: inject interrupts in any state
Date: Thu, 1 Nov 2012 05:45:31 -0400 (EDT)

> On 10/31/12 13:53, Alon Levy wrote:
> > I cannot find a reason we asserted that injecting interrupts happen
> > only
> > when the vm is running. This is right now the cause of spice
> > crashing
> > due to the new interface_client_set_capabilities being called when
> > the
> > vm is stopped, this happens if a user stops the vm or the vm
> > reboots and
> > a spice connection is dropped / created meanwhile.
> > 
> > Sending as RFC since I'm not sure what the original reason for the
> > assert is, git history is no help, it's in the first commit.
> 
> The problem is migration.  qxl_send_events modifies guest state, and
> there are phases during migration where modifying guest state is a
> no-go.  You'll loose events, either because the guest state update on
> the source side came to late so it isn't send over or because the
> update
> on the target side came to early so loadvm will overwrite it.
> 
> Disallowing events when the vm is stopped catches more cases than
> needed, we could change it.  But that wouldn't fix the bug at hand,
> it
> would only make it harder to trigger.
> 
> IMO spice-server must not call interface_client_set_capabilities when
> the vm is not running.  After all we notify spice-server about the vm
> stop/start events for a reason ...

OK, I agree that should be fixed, we can queue this until the vm starts running 
in spice-server.
But having an assert on notify in qemu is also wrong - and the only way to fix 
it like you pointed out without dropping the event is to queue it as well.

So which will it be, queue in spice or in qemu? qemu seems a simpler place to 
catch everything.

> 
> cheers,
>   Gerd
> 
> 
> 



reply via email to

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