Change log:

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).

This is out of RFC, since we have two commands which are useful
to discover supported group types (ATM can be none or SR-IOV).


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        | 540 +++++++++++++++++++++++++++++++++++++++++++++++
 content.tex      | 112 +++++++++-
 introduction.tex |   3 +
 3 files changed, 653 insertions(+), 2 deletions(-)
 create mode 100644 admin.tex

-- 
MST


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

Reply via email to