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 <jfreim...@redhat.com>
I think we can make this change under the trivial changes rule, thanks! > > regards, > Jens --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org