On Mon, Mar 11, 2019 at 09:59:32PM +0100, Cédric Le Goater wrote: > On 2/26/19 5:17 AM, David Gibson wrote: > > On Fri, Feb 22, 2019 at 02:13:22PM +0100, Cédric Le Goater wrote: > >> Instead of switching off the sources, set their state to PENDING to > >> possibly catch a hotplug event occuring while the VM is stopped. At > >> resume, check the previous state and if an interrupt was queued, > >> generate a trigger. > > > > First, I think it would be better to fold this fix into the patch > > introducing the state change handlers.> > > Second, IIUC this would handle any instance of an irq being triggered > > while the VM is stopped. > > yes. > > > Hotplug interrupts is one obvious case of that, but I'm not sure its > > the only one. > > Do we really need to support device hotplug when the VM is stopped ? > Is that a libvirt requirement ?
I'm not actually sure, but I think it's the right thing to do.
Interrupts are asynchronous by nature, so it makes sense that they can
occur while the machine is otherwise stopped.
> > VFIO devices could interrupt while the VM is stopped, I think.
>
> If the guest has configured and mapped the IRQs, I would say yes.
>
> > Maybe even emulated devices
> > depending on how their synchronization with the cpu run state works.
>
> The console is one example.
>
> > There might be other cases. Does that sound right to you?
>
> yes.
>
> Supporting interrupts while a VM is stopped seems like a weird
> test scenario to me. Should we or should we not ?
I think we should.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
