Re: [virtio-dev] [PATCH v3] ACCESS_PLATFORM/ORDER_PLATFORM

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Dec 06, 2018 at 01:24:32PM +0100, Jens Freimann wrote:
> On Mon, Nov 26, 2018 at 08:03:37PM -0500, Michael S. Tsirkin wrote:
> > diff --git a/content.tex b/content.tex
> > index c346183..5582c1c 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -5452,26 +5452,48 @@ Descriptors} and \ref{sec:Packed Virtqueues / Indirect Flag: Scatter-Gather Supp
> >   \item[VIRTIO_F_VERSION_1(32)] This indicates compliance with this
> >     specification, giving a simple way to detect legacy devices or drivers.
> > 
> > -  \item[VIRTIO_F_IOMMU_PLATFORM(33)] This feature indicates that the device is
> > +  \item[VIRTIO_F_ACCESS_PLATFORM(33)] This feature indicates that
> > +  the device can be used on a platform where device access to data
> > +  in memory is limited and/or translated. E.g. this is the case if the device can be located
> >   behind an IOMMU that translates bus addresses from the device into physical
> > -  addresses in memory.  If this feature bit is set to 0, then the device emits
> > -  physical addresses which are not translated further, even though an IOMMU
> > -  may be present.
> > +  addresses in memory, if the device can be limited to only access
> > +  certain memory addresses or if special commands such as
> > +  a cache flush can be needed to synchronise data in memory with
> > +  the device. Whether accesses are actually limited or translated
> > +  is described by platform-specific means.
> > +  If this feature bit is set to 0, then the device
> > +  has same access to memory addresses supplied to it as the
> > +  driver has.
> > +  In particular, the device will always use physical addresses
> > +  matching addresses used by the driver (typically meaning
> > +  physical addresses used by the CPU)
> > +  and not translated further, and can access any address supplied to it by
> > +  the driver. When clear, this overrides any platform-specific description of
> > +  whether device access is limited or translated in any way, e.g.
> > +  whether an IOMMU may be present.
> >   \item[VIRTIO_F_RING_PACKED(34)] This feature indicates
> >   support for the packed virtqueue layout as described in
> >   \ref{sec:Basic Facilities of a Virtio Device / Packed Virtqueues}~\nameref{sec:Basic Facilities of a Virtio Device / Packed Virtqueues}.
> >   \item[VIRTIO_F_IN_ORDER(35)] This feature indicates
> >   that all buffers are used by the device in the same
> >   order in which they have been made available.
> > -  \item[VIRTIO_F_IO_BARRIER(36)] This feature indicates
> > -  that the device needs the driver to use the barriers
> > -  suitable for hardware devices.  Some transports require
> > -  barriers to ensure devices have a consistent view of
> > -  memory.  When devices are implemented in software a
> > -  weaker form of barrier may be sufficient and yield
> > -  better performance.  This feature indicates whether
> > -  a stronger form of barrier suitable for hardware
> > -  devices is necessary.
> > +  \item[VIRTIO_F_ORDER_PLATFORM(36)] This feature indicates
> > +  that memory accesses by the driver and the device are ordered
> > +  in a way described by the platform.
> > +
> > +  If this feature bit is negotiated, the ordering in effect for any
> > +  memory accesses by the driver that need to be ordered in a specific way
> > +  with respect to accesses by the device is the one suitable for devices
> > +  described by the platform.
> 
> I had to read this sentence several times. How about: "Some memory
> accesses by the driver need to be ordered in a specific way with
> respect to accesses by the device. If this feature bit is negotiated,
> these accesses need to match the ordering requirements of devices as
> described for the platform."
> 
> In any case:
> 
> Reviewed-by: Jens Freimann <jfreimann@redhat.com>

I think we can make this change under the trivial changes rule, thanks!

> 
> regards,
> Jens