[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
On Tue, Aug 03, 2021 at 02:33:20PM +0800, Jason Wang wrote: > å 2021/7/26 äå11:07, Stefan Hajnoczi åé: > > I guess this is just a summary of what we've already discussed and not > > new information. I think an implementation today would use DBus VMState > > to transfer implementation-specific device state (an opaque blob). > > > Instead of trying to migrate those opaque stuffs which is kind of tricky, I > wonder if we can avoid them by recording the mapping in the shared > filesystem itself. The problem is that virtiofsd has no way of reopening the exact same files without Linux file handles. So they need to be transferred to the destination (or stored on a shared file system as you suggested), regardless of whether they are part of the VIRTIO spec's device state or not. Implementation-specific state can be considered outside the scope of the VIRTIO spec. In other words, we could exclude it from the VIRTIO-level device state that save/load operate on. This does not solve the problem, it just shifts the responsibility to the virtualization stack to migrate this state. The Linux file handles or other virtiofsd implementation-specific state would be migrated separately (e.g. using DBus VMstate) so that by the time the destination device does a VIRTIO load operation, it has the necessary implementation-specific state ready. I prefer to support in-band migration of implementation-specific state because it's less complex to have a single device state instead of splitting it. Is this the direction you were thinking in? Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]