[virtio-dev] Re: [PATCH v13 00/10] Introduce device group and device management

[Jiri Pirko <jiri@nvidia.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.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org