Change log:
since v10:
addressed lots of comments by Jiri, Stefan. Cornelia, Lngshan, Parav,
Max
Cornelia, do you want to pick up 10/10 separately?
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?
left as is for now just in case we soon get more admin things which are
not group administration. easy to change later.
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 | 586 +++++++++++++++++++++++++++++++++++++++++++++++
content.tex | 113 ++++++++-
introduction.tex | 3 +
3 files changed, 700 insertions(+), 2 deletions(-)
create mode 100644 admin.tex
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
