virtio — archive

[Jiri Pirko <mst@redhat.com>]

Fri, May 05, 2023 at 05:40:33PM CEST, mst@redhat.com 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. > > >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 ++ Michael, not sure if it is problem of this patchset or on my side but makepdf fails to build this. With master branch, works fine.