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 Wed, Aug 04, 2021 at 09:42:34AM +0800, Jason Wang wrote:
> å 2021/8/3 äå8:22, Dr. David Alan Gilbert åé:
> > * Jason Wang (jasowang@redhat.com) wrote:
> > > å 2021/8/3 äå6:37, Stefan Hajnoczi åé:
> > > > On Tue, Aug 03, 2021 at 02:33:20PM +0800, Jason Wang wrote:
> > > > > å 2021/7/26 äå11:07, Stefan Hajnoczi åé:
> > I'd expect how Linux implementations work to be standardised.
> Does it mean we need:
> 1) port virtiofsd to multiple platforms

Correct migration requires a non-POSIX mechanism to reopen files (saving
inode numbers as you've suggested isn't enough). If that's unavailable
then it won't be possible to migrate safely.

> 2) only support live migration among virtiofds

We can standardize the device state representation for Linux passthrough
file systems and implement it in QEMU's virtiofsd and virtiofsd-rs.

However, it's technically possible for other virtiofsd implementations
to migrate too and they shouldn't be second-class citizens. QEMU's
virtiofsd isn't special and Linux passthrough file systems aren't

Some device state representations will apply to one specific virtiofs
implementation, so the value of standardizing it beyond choosing a
unique identifier to prevent collisions is questionable. Does the VIRTIO
TC want to spend time reviewing implementation-specific device state

What I suggest is to allow in-band implementation-specific device state
with a unique identifier that prevents migration between incompatible
implementations. Standardize device state representations that are
actually worth standardizing (like the Linux passthrough file system
where there are multiple implementations): implementors benefit from
using the standard because it saves them time and ensures migration


Attachment: signature.asc
Description: PGP signature

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