OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

å 2021/7/10 äå1:23, Eugenio Perez Martin åé:
   If I understand correctly, this is all
driven from the driver inside the guest, so for this to work
the guest must be running and already have initialised the driver.


As I see it, the feature can be driven entirely by the VMM as long as
it intercept the relevant configuration space (PCI, MMIO, etc) from
guest's reads and writes, and present it as coherent and transparent
for the guest. Some use cases I can imagine with a physical device (or
vp_vpda device) with VIRTIO_F_STOP:

It's basically for nested live migration. (E.g present a VIRTIO_F_STOP to L1 guest and above)

1) The VMM chooses not to pass the feature flag. The guest cannot stop
the device, so any write to this flag is an error/undefined.
2) The VMM passes the flag to the guest. The guest can stop the device.
2.1) The VMM stops the device to perform a live migration, and the
guest does not write to STOP in any moment of the LM. It resets the
destination device with the state, and then initializes the device.
2.2) The guest stops the device and, when STOP(32) is set, the source
VMM migrates the device status. The destination VMM realizes the bit,
so it sets the bit in the destination too after device initialization.
2.3) The device is not initialized by the guest so it doesn't matter
what bit has the HW, but the VM can be migrated.

Am I missing something?

Something like this, note that in any cases we should not let the L(x) guest to access the device status bit of L(x-1) directly. The VMM in L(x-1) is in charge of shadowing the device status (DRIVER_OK and STOP) correctly. If we want to migrate L(x) guest, VMM in L(x-1) needs to migrate the device status correctly and restore them in the destination:

1) The device status bit in L1 is implemented by L0 VMM

2) The device status bit in L2 is implemented by L1 VMM

3) If we need to migrate L1, we just migrate the L1 device status and restore it

4) If we need to migrate L2, we just migrate the L2 device status and restore it

E.g the logic of L0 VMM (source) is:

if L1_status | DRIVER_OK && !(L1_status | STOP):
ÂÂÂ set STOP to L0_status;
ÂÂÂ wait until STOP is set for L0_status;
save L1 state(status) and send it to destination

The logic of L0 VMM(dest) is:

get L1 state(status)
if L1_status | DRIVER_OK:
ÂÂÂ perform the L0 device initialization (e.g features based of L1 state)
ÂÂÂ propagate L1_status(DRIVER_OK|DRIVER_STOP) to the L0 device


For 2.1, STOP is set by source VMM by not recovered by source since it's not a state of L1 device

For 2.2, STOP is 'set' by L1 and shadowed by VMM, and it was recovered by the destination since it's a state of L1 device

For 2.3, STOP is not set by source and not recovered by destination since it's not a state of L1 device



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]