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

From
Michael S. Tsirkin
Date
2023-05-05T15:41:00+00:00
ID
Thread
[PATCH v13 00/10] Introduce device group and device management
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 ++  7 files changed, 707 insertions(+), 3 deletions(-)  create mode 100644 admin.tex

--
MST