[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/1] Removing RAMBlocks during migration
From: |
Yury Kotov |
Subject: |
Re: [RFC PATCH 0/1] Removing RAMBlocks during migration |
Date: |
Mon, 13 Jan 2020 17:18:54 +0300 |
Hi!
07.01.2020, 23:08, "Michael S. Tsirkin" <address@hidden>:
> On Fri, Jan 03, 2020 at 11:44:27AM +0000, Dr. David Alan Gilbert wrote:
>> > 1) Guest: writes to slot's pci config
>> > 2) QEMU: pcie_cap_slot_write_config -> pcie_unplug_device
>> >
>> > So, it's only guest driven action and qdev_unplug doesn't help here.
>>
>> Hmm we need to find a way to stop that; lets see if Michael Tsirkin has
>> any ideas (cc'd) - I'm thinking if we could defer the unplug until the
>> end of the migration we'd be OK; but it feels racy as to whether the
>> destination is started with the device that the guest is unplugging.
>>
>> Dave
>
> It's true - and same is possible with PCI, guest can remove device
> at will.
>
> Also, while libvirt learned not to start device del while migration
> is active, it's annoying to have to wait for device del
> to complete before migration can be started.
>
> I guess we can make device invisible to guest - that concept
> now exists because of failover, and can maybe be reused here.
>
> Alternatively or additionally - for a while now I wanted to only remove
> the device if guest powered it out and removal was requested. Again it
> might be easier now that we have a concept of an invisible device.
>
I sent an rfc patch that implements deferred device unplug:
pcie: Defer hot unplug until migration is complete
Please take a look at it.
Regards,
Yury