qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v3 2/5] virtio_net: Add support


From: Roman Kagan
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH v3 2/5] virtio_net: Add support for "Data Path Switching" during Live Migration.
Date: Mon, 14 Jan 2019 11:10:44 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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.



reply via email to

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