On Thu, 4 Oct 2018 13:24:40 -0400 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Thu, Oct 04, 2018 at 01:57:21PM +0200, Igor Mammedov wrote: > > On Wed, 3 Oct 2018 10:44:20 -0700 > > open sorcerer <0p3n.s0rc3...@gmail.com> wrote: > > > > > Hi, > > > > > > I am digging into an issue where qmp_device_del does not actually delete > > > devices when a guest OS is in prelaunch. This seems to be due to the guest > > > OS not handling ACPI events because it is not currently running. If I > > > assume correctly, qmp should allow you to add/remove devices while the > > > host > > > is down, or if not possible, publish an error message. > > may I ask why one would delete a device at -S pause point, isn't it easier > > to start QEMU without it, to begin with? > > > > > I think fixing this issue is as simple as making sure that the VM is in a > > > safe state to ignore the hotplug ACPI dance but eject the disk, something > > > like: > > in prelaunch runstate where '-S' option pauses VM, it is practically paused > > at the first instruction to be executed. So device_add at that point is > > considered as hotplug with all actions already executed on hardware level > > (interrupts sent, devices responsible for hotplug handling has changed > > state). > > So if one wished to delete device at that point, one would have to rollback > > related state changes. > > If one would additionally use -incoming CLI option, it becomes more > > complicated > > as we might endup in prelaunch runstate with VM in running state > > (see possible transitions in runstate_transitions_def[]) > > I'd say prelauch runstate can't be used for removing devices that do not > > support surprise removal (in our case PCI isn't). > > I'd say the point is this. In prelaunch guest did not observe any > device state yet, we could make device_add look just like > a non-hotplugged device. And we could make device_del pretend > there was a reset immediately afterwards. > > Not sure why it matters to anyone, but it's doable I think. in case we came to prelaunch from freshly started QEMU with -S and no other disrupting things in between /migration, chekpointing, .../ it's theoretically possible. However even then to make a clean device_del in that state for devices that expect guest cooperation, one would need chain unplug_request (which is what device_del translates to) with whatever hotunplug hw is used and simulate guest unplugging it. And then on top we might need to rebuild/reload firmware tables (ARM) (x86 should work as it will rebuild ACPI tables on the first access). In generic case we might need to fixup something else elsewhere. When I looked into early numa configuration, I've failed to convince myself that using prelaunch, changing its semantics to coldplug and fixing up already built machine as safe/robust thing to do.(Resulted prelaunch based RFC even worked fine, but I wouldn't bet it wouldn't fall apart or in all other combinations prelaunch runstate could be reached) As result we ended up with new preconfig option/runstate where to we can gradually move machine building steps. One possible way to deal with subject would be queue at preconfig stage -device/device_add and use this queue later to add devices to board (not sure if it's a sound idea in general). This early it should be possible to remove a device from queue. But why one would add device and immediately remove it ... :/
