On Thu, Oct 29, 2020 at 2:35 PM Dixit, Ashutosh <ashutosh.di...@intel.com> wrote: > On Thu, 29 Oct 2020 04:53:09 -0700, Arnd Bergmann wrote: > > > > - PCIe endpoint, with the endpoint controlling the virtio configuration > > - PCIe endpoint, with the host (the side that has the pci_driver) > > controlling > > the virtio configuration > > - NTB connections > > - your loopback mode > > - Virtio tunnels between VM guests (see > > https://www.linaro.org/projects/#STR) > > - Intel MIC (to be removed, but it would be wrong to make assumptions that > > cannot be made on that type of hardware) > > A virtio interface being one between host and guest is inherently > asymmetric. The whole innovation of the VOP design was to treat Linux on a > PCIe device as a guest, there was even talk at some point of the "guest" > being managed via libvirt. So here host and guest retain their specific > role/personality. The host "inserts" devices which appear in the guest > e.g. So I am not sure how this asymmetry plays in the scenarios mentioned > above.
This is the reason I listed the PCIe endpoint mode twice. I expect that some use cases require the same setup as MIC, with Linux on some kind of PCIe add-on card using devices that are implemented on the host. In other cases we may need the opposite: you may have a PCIe add-on card that provides arbitrary services to the host in the same way that most PCIe endpoint devices work. An example might be a smart NIC running a standalone Linux, but implementing virtio-net to avoid the need for custom drivers on the host. In the endpoint framework, it is always the endpoint that decides what PCI devices it wants to implement, but in case of VOP that device could be either the side that configures and implements the virtio devices, or the side that probes and uses them. Arnd