Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201023092650.GB29066@infradead.org> <VI1PR04MB4960E9ECD7310B8CA1E053DC92190@VI1PR04MB4960.eurprd04.prod.outlook.com>
 <20201027062802.GC207971@kroah.com> <VI1PR04MB4960C0E76374B2775D99A82192160@VI1PR04MB4960.eurprd04.prod.outlook.com>
 <20201027151106.e4skr6dsbwvo4al6@axis.com> <VI1PR04MB49603783EF3FD3F3635FCDAF92170@VI1PR04MB4960.eurprd04.prod.outlook.com>
 <93bd1c60ea4d910489a7592200856eaf8022ced0.camel@intel.com>
 <AM0PR04MB4947F01860DE953B8496FA8892170@AM0PR04MB4947.eurprd04.prod.outlook.com>
 <CAK8P3a1JRx32VfFcwFpK0i6F5MQMCK-yCKw8=d_R08Y3iQ7wLQ@mail.gmail.com>
 <CAK8P3a3u06ZHdAb_n3byTqfxAvy_wi48X1g0N4ODuH2uEM0xLA@mail.gmail.com>
 <20201029100727.trbppgbusd5vogpz@axis.com> <CAK8P3a3T2Riy-vfd8RcdWeeER4usc2m78rkmx4Q_8N3zGA6r_A@mail.gmail.com>
 <87mu05f94g.wl-ashutosh.dixit@intel.com>
In-Reply-To: <87mu05f94g.wl-ashutosh.dixit@intel.com>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Thu, 29 Oct 2020 14:54:37 +0100
Message-ID: <CAK8P3a0j8bi64yzPA=p9uP5cU8Z1NAS7Bp5a1BVjFBt-4LLzGQ@mail.gmail.com>
Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used ring
To:     "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc:     Vincent Whitchurch <vincent.whitchurch@axis.com>,
        Sherry Sun <sherry.sun@nxp.com>,
        "Dutt, Sudeep" <sudeep.dutt@intel.com>,
        dl-linux-imx <linux-imx@nxp.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "kishon@ti.com" <kishon@ti.com>,
        "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Oct 29, 2020 at 2:35 PM Dixit, Ashutosh
<ashutosh.dixit@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