[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v2 13/13] spapr/xive: fix device hotplug when VM i
Re: [Qemu-ppc] [PATCH v2 13/13] spapr/xive: fix device hotplug when VM is stopped
Wed, 13 Mar 2019 15:11:11 +1100
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.
> > 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?
> 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_!
Description: PGP signature