Re: [virtio-comment] [PATCH v10 00/10] Introduce device group and device management

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Mar 07, 2023 at 08:21:54AM +0100, Jiri Pirko wrote:
> Mon, Mar 06, 2023 at 11:54:45PM CET, mst@redhat.com wrote:
> >On Mon, Mar 06, 2023 at 01:29:30PM +0100, Jiri Pirko wrote:
> >> Thu, Mar 02, 2023 at 02:04:48PM CET, mst@redhat.com wrote:
> >> 
> >> [...]
> >> 
> >> >
> >> >TODO (maybe?) - probably ok to defer until this part is upstream:
> >> >
> >> >	Add "all members" member id.
> >> >
> >> >	Add commands for MSI, feature discovery.
> >> >
> >> >	Add commands for transport vq.
> >> >
> >> >
> >> >My intent is to try and support both SR-IOV and SIOV
> >> >usecases with the same structure and maybe even the same
> >> >VQ.
> >> 
> >> Sorry to be late to the party, I'm trying to catch up. Is it common to
> >> have cover letter for features this brief? I mean, from the cover
> >> letter, I'm totally unable to understand what you are introducing here.
> >> 
> >> Could you elaborate about what you are aiming to achive with this?
> >> Could you shed some usecases perhaps?
> >> 
> >> I have to be missing something obvious, but I don't get why any notion
> >> of SR-IOV could be beneficial for virtio.
> >> 
> >
> >Good point, I'll add a bit of motivation.
> >
> >For SR-IOV, it is not unusual for PFs to excercise control over VFs.
> 
> I understand the concepts of SR-IOV. Yet I fail to see the need of such
> concept in virtio world. SR-IOV is very specific solution for PCI
> functions instantiation, and I believe that it is already considered
> quite limiting in many aspects. Does not make sense to me to introduce
> it for virtio. But again, I may be missing something crucial, I just
> would like to see the motivation, needs, usecases for this crystal
> clear, which is opposite to the current cover letter I'm afraid :/

First people are asking for it because it's out there, however limiting
it is. In fact Nvidia is - why don't you talk to Parav here and tell
him that SR-IOV is legacy and there's no need to support.




> 
> >There is interest in the community to include an interface to allow this
> >in the virtio spec, when the PF is a virtio device.  This is what this
> >patch does.
> 
> Yeah, but why? As I asked before, what are the usecases? The fact there
> is interest in the community does not mean it makes sense to have it :)
> 

If people want to build such hardware it will need some interface.
Far better to have it standard.


But generally e.g. intel already said they will reuse this
same structure with a different group type for SIOV support.
I'll mention this in the cover letter.

> >
> >
> >
> >
> >> >
> >> >For example, it might make sense to split creating/destroying
> >> >SIOV devices from the transport passing data from the guest - the
> >> >driver would then not negotiate VIRTIO_F_SR_IOV (which
> >> >then means auto-provisioning).
> >> >
> >> >This is out of RFC, since we have two commands which are useful
> >> >to discover supported group types (ATM can be none or SR-IOV).
> >> >
> >> >
> >> >Michael S. Tsirkin (10):
> >> >  virtio: document forward compatibility guarantees
> >> >  admin: introduce device group and related concepts
> >> >  admin: introduce group administration commands
> >> >  admin: introduce virtio admin virtqueues
> >> >  pci: add admin vq registers to virtio over pci
> >> >  mmio: document ADMIN_VQ as reserved
> >> >  ccw: document ADMIN_VQ as reserved
> >> >  admin: command list discovery
> >> >  admin: conformance clauses
> >> >  ccw: document more reserved features
> >> >
> >> > admin.tex        | 540 +++++++++++++++++++++++++++++++++++++++++++++++
> >> > content.tex      | 112 +++++++++-
> >> > introduction.tex |   3 +
> >> > 3 files changed, 653 insertions(+), 2 deletions(-)
> >> > create mode 100644 admin.tex
> >> >
> >> >-- 
> >> >MST
> >> >
> >> >
> >> >This publicly archived list offers a means to provide input to the
> >> >OASIS Virtual I/O Device (VIRTIO) TC.
> >> >
> >> >In order to verify user consent to the Feedback License terms and
> >> >to minimize spam in the list archive, subscription is required
> >> >before posting.
> >> >
> >> >Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> >> >Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> >> >List help: virtio-comment-help@lists.oasis-open.org
> >> >List archive: https://lists.oasis-open.org/archives/virtio-comment/
> >> >Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> >> >List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> >> >Committee: https://www.oasis-open.org/committees/virtio/
> >> >Join OASIS: https://www.oasis-open.org/join/
> >> >
> >> 
> >> This publicly archived list offers a means to provide input to the
> >> OASIS Virtual I/O Device (VIRTIO) TC.
> >> 
> >> In order to verify user consent to the Feedback License terms and
> >> to minimize spam in the list archive, subscription is required
> >> before posting.
> >> 
> >> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> >> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> >> List help: virtio-comment-help@lists.oasis-open.org
> >> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> >> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> >> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> >> Committee: https://www.oasis-open.org/committees/virtio/
> >> Join OASIS: https://www.oasis-open.org/join/
> >