virtio — archive

[PATCH v10 00/10] Introduce device group and device management

From: Michael S. Tsirkin <[email protected]>
To: [email protected]
Date: Mon, 06 Mar 2023 22:55:00 -0000

On Mon, Mar 06, 2023 at 01:29:30PM +0100, Jiri Pirko wrote: > Thu, Mar 02, 2023 at 02:04:48PM CET, [email protected] 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. 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. > > > >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: [email protected] > >Unsubscribe: [email protected] > >List help: [email protected] > >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: [email protected] > Unsubscribe: [email protected] > List help: [email protected] > 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/