virtio — archive

[Michael S. Tsirkin]

On Fri, May 05, 2023 at 11:40:33AM -0400, Michael S. Tsirkin wrote: > > > > Change log: > > since 13: > command specific data is u8 again > exclude admin queues in blk's num_queues > minor other tweaks > > since 11: > addressed lots of comments, all minor. consistency with > outstanding number->index and queue->enqueue work > i did not intentionally drop any reviewed-by tags > as all changes are minor - if yours is missing it is > because I forgot to record it, sorry > > one "breaking" change in response to stefan's comment: > in patch 5, num_queues has been specified not to include admin > queues: just regular ones. > > since v10: > addressed lots of comments by Jiri, Stefan. Cornelia, Lngshan, Parav, Max > > since v9: > addressed comments by Parav, Max, Cornelia, David and Zhu Lingshan: > added link to errno header from Linux > rename _MEM to _MEMBER > admin vq num is zero based > clarify who sends commands where > minor english tweaks > clarify command length > specify interaction with sriov capability > correct commit log - NumVFs can be 0 > > i could not decide what should happen when VFs are > disabled. for now did not specify. > > since v8: > addressed comments by Cornelia - as we agreed on list > > since v7: > make high level error codes match linux, with virtio specific codes > in a separate field > renamed _ACCEPT to _USE since that's what it does > clarified forward compatibility and non pci transports > support multiple admin vqs > conformance statements > lots of changes all over the place to I changed author from Max > to myself. Don't need to take credit but also don't want > to blame Max for my mistakes. > > since v6: > > - removed some extentions intended for future use. > We'll do them when we get there. > > - brought back command list query from v5 in a simplified form - > it's here to address the case where a single parent > can address multiple groups, such as PF addressing > transport vq and sriov vfs. > > - attempt to make terminology more formal. > In particular a term for whoever controls the group. > I am still going back > and forth between "parent" and "owner" - owner might > be better after all since it will work if we ever > have a self group. For now it's parent. > > 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. Fixes: https://github.com/oasis-tcs/virtio-spec/issues/171 As there have only been tiny tweaks since v12, I'm starting a vote now. > > My intent is to try and support both SR-IOV and SIOV > usecases with the same structure and maybe even the same > VQ. > > 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). > > More ideas for use-cases: > virtio VF features query and configuration space provisioning > virtio VF resource (queues, msix vectors count) provisioning > > > Future directions (shouldn't block this patch) > - aborting commands - left for later. or is vq reset enough? > - should we rename structures from admin to group admin? > > > 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 | 584 +++++++++++++++++++++++++++++++ > content.tex | 62 +++- > device-types/blk/description.tex | 2 +- > introduction.tex | 3 + > transport-ccw.tex | 14 + > transport-mmio.tex | 12 + > transport-pci.tex | 33 ++ > 7 files changed, 707 insertions(+), 3 deletions(-) > create mode 100644 admin.tex > > -- > MST