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 <[email protected]>
I think we can make this change under the trivial changes rule, thanks!
>
> regards,
> Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
