[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v1 0/2] transport-pci: Introduce legacy registers access using AQ
On Wed, May 03, 2023 at 06:26:57AM +0300, Parav Pandit wrote: > This patch introduces legacy registers access commands for the owner > group member PCI PF to access the legacy registers of the member VFs. > > If in future any SIOV devices to support legacy registers, they > can be easily supported using same commands by using the group > member identifiers of the future SIOV devices. Absolutely, but maybe we should not create work for this case by repeating PF/VF terminology everywhere? > More details as overview, motivation, use case are further described > below. > > Patch summary: > -------------- > patch-1 adds administrative virtuqueue commands > patch-2 adds its conformance section > > This short series is on top of [1]. > It uses the newly introduced administrative virtqueue facility with 3 new > opcodes and uses the existing virtio_admin_cmd. > > It is expected to go another rebase once v13 for [1] is rolled out and merged. > > [1] https://lore.kernel.org/virtio-comment/cover.1682354275.git.mst@redhat.com/T/#t > > Usecase: > -------- > 1. A hypervisor/system needs to provide transitional > virtio devices to the guest VM at scale of thousands, > typically, one to eight devices per VM. > > 2. A hypervisor/system needs to provide such devices using a > vendor agnostic driver in the hypervisor system. > > 3. A hypervisor system prefers to have single stack regardless of > virtio device type (net/blk) and be future compatible with a > single vfio stack using SR-IOV or other scalable device > virtualization technology to map PCI devices to the guest VM. > (as transitional or otherwise) > > Motivation/Background: > ---------------------- > The existing virtio transitional PCI device is missing support for > PCI SR-IOV based devices. Currently it does not work beyond > PCI PF, or as software emulated device in reality. Currently it > has below cited system level limitations: > > [a] PCIe spec citation: > VFs do not support I/O Space and thus VF BARs shall not indicate I/O Space. > > [b] cpu arch citiation: > Intel 64 and IA-32 Architectures Software Developerâs Manual: > The processorâs I/O address space is separate and distinct from > the physical-memory address space. The I/O address space consists > of 64K individually addressable 8-bit I/O ports, numbered 0 through FFFFH. > > [c] PCIe spec citation: > If a bridge implements an I/O address range,...I/O address range will be > aligned to a 4 KB boundary. > > Above usecase requirements can be solved by PCI PF group owner enabling > the access to its group member PCI VFs legacy registers using an admin > virtqueue of the group owner PCI PF. > > Software usage example: > ----------------------- > The most common way to use and map to the guest VM is by > using vfio driver framework in Linux kernel. > > +----------------------+ > |pci_dev_id = 0x100X | > +---------------|pci_rev_id = 0x0 |-----+ > |vfio device |BAR0 = I/O region | | > | |Other attributes | | > | +----------------------+ | > | | > + +--------------+ +-----------------+ | > | |I/O BAR to AQ | | Other vfio | | > | |rd/wr mapper | | functionalities | | > | +--------------+ +-----------------+ | > | | > +------+-------------------------+-----------+ > | | > +----+------------+ +----+------------+ > | +-----+ | | PCI VF device A | > | | AQ |-------------+---->+-------------+ | > | +-----+ | | | | legacy regs | | > | PCI PF device | | | +-------------+ | > +-----------------+ | +-----------------+ > | > | +----+------------+ > | | PCI VF device N | > +---->+-------------+ | > | | legacy regs | | > | +-------------+ | > +-----------------+ > > 2. Virtio pci driver to bind to the listed device id and > use it as native device in the host. > > 3. Use it in a light weight hypervisor to run bare-metal OS. > > Please review. > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/167 > Signed-off-by: Parav Pandit <parav@nvidia.com> I don't see an overview here though. > --- > changelog: > v0->v1: > - addressed comments, suggesetions and ideas from Michael Tsirkin and Jason Wang > - far more simpler design than MMR access > - removed complexities of MMR device ids > - removed complexities of MMR registers and extended capabilities > - dropped adding new extended capabilities because if if they are > added, a pci device still needs to have existing capabilities > in the legacy configuration space and hypervisor driver do not > need to access them > > > Parav Pandit (2): > transport-pci: Introduce legacy registers access commands > transport-pci: Add legacy register access conformance section > > admin.tex | 5 +- > conformance.tex | 2 + > transport-pci-vf-regs.tex | 115 ++++++++++++++++++++++++++++++++++++++ > transport-pci.tex | 2 + > 4 files changed, 123 insertions(+), 1 deletion(-) > create mode 100644 transport-pci-vf-regs.tex > > -- > 2.26.2
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]