On Thu, Jan 10, 2019 at 11:09:09PM -0800, si-wei liu wrote:
> On 01/10/2019 07:20 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 10, 2019 at 06:09:23PM -0800, si-wei liu wrote:
> > >
> > > On 01/09/2019 07:56 AM, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 07, 2019 at 05:29:41PM -0500, Venu Busireddy wrote:
> > > > > @@ -207,6 +226,14 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
> > > > > int i;
> > > > > for (i = 0; i < ACPI_PCIHP_MAX_HOTPLUG_BUS; ++i) {
> > > > > + /*
> > > > > + * Set the acpi_pcihp_pci_status[].down bits of all the
> > > > > + * failover_primary devices so that the devices are ejected
> > > > > + * from the guest. We can't use the qdev_unplug() as well as
> > > > > the
> > > > > + * hotplug_handler to unplug the devices, because the guest
> > > > > may
> > > > > + * not be in a state to cooperate.
> > > > > + */
> > > > > + acpi_pcihp_cleanup_failover_primary(s, i);
> > > > > acpi_pcihp_update_hotplug_bus(s, i);
> > > > > }
> > > > > }
> > > > I really don't want acpi to know anything about failover.
> > > >
> > > > All that needs to happen is sending a device delete request
> > > > to guest. Should work with any hotplug removal:
> > > > pci standard,acpi, etc.
> > > >
> > > As the code comments above indicated, there was issue uncovered that the
> > > guest may not be in a state to respond to interrupt during reboot.
> > If you request removal then hotplug machinery normally will eject
> > the device on system reset. You need to request it early enough though.
> With asynchronous nature of interrupt injection and guest handling, there's
> no way you can guarantee it's early enough, do you?
I wonder if it can be better addressed by some "eject-on-parent-reset"
or "eject-on-vm-reset" property which would automatically eject the
device when the parent bridge or the vm is reset, so that the device is
in predictably unplugged state on every boot?
Roman.
