Subject should be "document SR-IOV driver requirements" I think. On Thu, Jun 07, 2018 at 09:50:50AM +0800, Tiwei Bie wrote: > Document the device and driver behaviours for SR-IOV. > > Suggested-by: Michael S. Tsirkin <m...@redhat.com> > Signed-off-by: Tiwei Bie <tiwei....@intel.com> > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/13 > --- > content.tex | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/content.tex b/content.tex > index 73981b7..3b45a6c 100644 > --- a/content.tex > +++ b/content.tex > @@ -5387,6 +5387,18 @@ A driver SHOULD accept VIRTIO_F_IO_BARRIER if it is > offered. > If VIRTIO_F_IO_BARRIER has been negotiated, a driver MUST use > the barriers suitable for hardware devices. > > +If VIRTIO_F_SR_IOV has been negotiated, a driver can enable
can -> MAY > +virtual functions through the device's PCI SR-IOV capability > +structure. A driver MUST NOT negotiate VIRTIO_F_SR_IOV if > +the device does not have a PCI SR-IOV capability structure > +or is not a PCI device. A driver MUST negotiate > +VIRTIO_F_SR_IOV and complete the feature negotiation > +(including checking the FEATURES_OK \field{status} bit) OK. > before > +the first time to enable virtual functions before enabling virtual functions > through the device's > +PCI SR-IOV capability structure, I'd end the sentence here and start a new one. > and the driver MAY remember > +the VIRTIO_F_SR_IOV feature bit negotiation result until it > +unbinds from the device. > + I'm not sure what does this mean. We generally take it to mean the DRIVER status bit and that gets cleared by device reset. How about: After once successfully negotiating VIRTIO_F_SR_IOV, the driver MAY enable virtual functions through the device's PCI SR-IOV capability structure even if the device or the system has been fully or partially reset, and even without re-negotiating VIRTIO_F_SR_IOV after the reset. > \devicenormative{\section}{Reserved Feature Bits}{Reserved Feature Bits} > > A device MUST offer VIRTIO_F_VERSION_1. A device MAY fail to operate further > @@ -5403,6 +5415,10 @@ buffers in the same order in which they have been > available. > A device MAY fail to operate further if VIRTIO_F_IO_BARRIER > is not accepted. > > +A device SHOULD offer VIRTIO_F_SR_IOV if it is a PCI device > +and presents a PCI SR-IOV capability structure, otherwise > +it MUST NOT offer VIRTIO_F_SR_IOV. > + > \section{Legacy Interface: Reserved Feature Bits}\label{sec:Reserved Feature > Bits / Legacy Interface: Reserved Feature Bits} > > Transitional devices MAY offer the following: This part has been committed aleady. I suspect we want to add somewhere in the general section: If device has successfully negotiated a set of features at least once (by setting the FEATURES_OK \field{status} bit) then it SHOULD NOT fail re-negotiation of the same set of features after a device or system reset. Failure to do so would interfere with resume from suspend and error recovery. That's a general statement though, I think it's worth a separate issue in github. > -- > 2.17.0 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org