From: Tiwei Bie <tiwei.bie@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: cohuck@redhat.com, stefanha@redhat.com, pbonzini@redhat.com,
virtio-dev@lists.oasis-open.org, dan.daly@intel.com,
alexander.h.duyck@intel.com, mark.d.rustad@intel.com,
cunming.liang@intel.com, zhihong.wang@intel.com
Subject: Re: [virtio-dev] Re: [PATCH v1] content: support SR-IOV
Date: Tue, 22 May 2018 10:40:57 +0800 [thread overview]
Message-ID: <20180522024057.GA21227@debian> (raw)
In-Reply-To: <20180522044253-mutt-send-email-mst@kernel.org>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2018-05-22 2:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 10:52 [virtio-dev] [PATCH v1] content: support SR-IOV Tiwei Bie
2018-05-21 22:32 ` [virtio-dev] " Michael S. Tsirkin
2018-05-22 1:28 ` Tiwei Bie
2018-05-22 1:55 ` Michael S. Tsirkin
2018-05-22 2:40 ` Tiwei Bie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180522024057.GA21227@debian \
--to=tiwei.bie@intel.com \
--cc=alexander.h.duyck@intel.com \
--cc=cohuck@redhat.com \
--cc=cunming.liang@intel.com \
--cc=dan.daly@intel.com \
--cc=mark.d.rustad@intel.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhihong.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.