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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev 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


On Tue, Jul 20, 2021 at 12:48:43PM +0200, Cornelia Huck wrote:
> On Tue, Jul 20 2021, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> 
> > On Tue, Jul 20, 2021 at 11:04:55AM +0800, Jason Wang wrote:
> >> Let me clarify, I agree we can't have a standard device state for all kinds
> >> of device.
> >> 
> >> That's way I tend to leave them to be device specific. (but not
> >> implementation specific)
> >
> > Unfortunately device state is sometimes implementation-specific. Not
> > because the device is proprietary, but because the actual state is
> > meaningless to other implementations.
> >
> > I mentioned virtiofs as an example where file system backends can be
> > implemented in completely different ways so the device state cannot be
> > migrated between implementations.
> >
> >> But we can generalize the virtqueue state for sure.
> >
> > I agree and also that some device types can standardize their device
> > state representations. But I think it's a technical requirement to
> > support implementation-specific state for device types where
> > cross-implementation migration is not possible.
> >
> > I'm not saying the implementation-specific state representation has to
> > be a binary blob. There could be an identifier registry to ensure live
> > migration compatibility checks can be performed. There could also be a
> > standard binary encoding for migration data. But the contents will be
> > implementation-specific for some devices.
> 
> Can we at least put those implementation-specific states into some kind
> of structured, standardized form? E.g. something like
> 
> <type category: file system backend data>
> <type identifier: file system foo>
> <length>
> <data>
> 
> so that we can at least do compat checks for "I know how to handle foo"?

Yes, that's what I was trying to describe.

Stefan

Attachment: signature.asc
Description: PGP signature



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