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: [RFC] VIRTIO_F_IO_BARRIER: use I/O barriers in driver


On Wed, Apr 25, 2018 at 03:23:39PM +0200, Paolo Bonzini wrote:
> On 25/04/2018 10:23, Tiwei Bie wrote:
> > There will be hardware virtio devices in the future, which
> > require drivers to use the barriers suitable for I/O device,
> > compared with software virtio devices which just require
> > drivers to use the barriers suitable for CPU core.
> > 
> > To fix the ordering issue for hardware virtio devices, add
> > a new feature: VIRTIO_F_IO_BARRIER. When negotiated, driver
> > will use the barriers suitable for I/O device.
> 
> Unfortunately this doesn't work as mentioned earlier.  Virtio live
> migration assumes that features are safe if you have them on the
> destination but not on the source; this feature however works the
> opposite way.
> 
> Paolo

That's a qemu code property, and it's because it does not
migrate host properties right now. When implementing this feature we
can add migration of host features.

But that's only if we want to catch mis-use. We can also
punt it up the stack and say feature flags must match
on source and destination, and if they do not the problem
is between the keyboard and the chair.


-- 
MST


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