[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH v1] content: support SR-IOV
On Tue, May 22, 2018 at 04:55:05AM +0300, Michael S. Tsirkin wrote: > On Tue, May 22, 2018 at 09:28:22AM +0800, Tiwei Bie wrote: > > On Tue, May 22, 2018 at 01:32:29AM +0300, Michael S. Tsirkin wrote: > > > On Mon, May 21, 2018 at 06:52:06PM +0800, Tiwei Bie wrote: [...] > > > > If VIRTIO_F_IN_ORDER has been negotiated, a device MUST use > > > > buffers in the same order in which they have been available. > > > > > > > > +A device SHOULD offer VIRTIO_F_SR_IOV if it presents a PCI > > > > +SR-IOV capability structure. A device MAY fail to operate > > > > +further if VIRTIO_F_SR_IOV is not accepted. > > > > > > Why is the last sentence here? What are you trying to accomplish? It > > > seems that if we allow drivers not to accept the bit, we should require > > > the devices to function without it or at least not go out of our way to > > > say they do not have to. > > > > The last sentence "A device MAY fail to operate further > > if VIRTIO_F_SR_IOV is not accepted" means if the driver > > doesn't accept this feature, the device may fail to work, > > e.g. setting VIRTIO_CONFIG_S_FEATURES_OK may fail. And > > in this case (i.e. the device fails to work), it will be > > necessary for driver to accept this feature in order to > > work with this device. > > > > So it's not to allow drivers not to accept the feature, > > instead, it just tells device's behaviour (i.e. device > > may fail to work) if this feature isn't accepted. And > > it leaves the choice to device's implementation. > > The choice is always there. However the preferred response > to features is for drivers only use what they actually > need, and devices to try to accomodate subsets of features. > > Is there a reason for this feature to be different? > > > > It's similar to the description for the IOMMU_PLATFORM > > feature: > > > > """ > > A device SHOULD offer VIRTIO_F_IOMMU_PLATFORM if it is behind an IOMMU that > > translates bus addresses from the device into physical addresses in memory. > > A device MAY fail to operate further if VIRTIO_F_IOMMU_PLATFORM is not > > accepted. > > """ > > Well IOMMU platform is very special in that it's a security feature. > We really can't support legacy drivers with these devices. > Most features aren't like this. > > Something like this would be appropriate for the barrier > feature. > > But this specific feature I don't see why can't driver just use > the PF. Okay. I'll remove the last sentence. Best regards, Tiwei Bie
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]