From: Manivannan Sadhasivam <manisadhasivam.linux@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-comment@lists.linux.dev, mie@igel.co.jp
Subject: Re: MSI for Virtio PCI transport
Date: Tue, 25 Jun 2024 14:49:11 +0530 [thread overview]
Message-ID: <20240625091911.GD2642@thinkpad> (raw)
In-Reply-To: <20240625034025-mutt-send-email-mst@kernel.org>
On Tue, Jun 25, 2024 at 03:52:30AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 24, 2024 at 09:49:57PM +0530, Manivannan Sadhasivam wrote:
> > Hi,
> >
> > We are looking into adapting Virtio spec for configurable physical PCIe endpoint
> > devices to expose Virtio devices to the host machine connected over PCIe. This
> > allows us to use the existing frontend drivers on the host machine, thus
> > minimizing the development efforts. This idea is not new as some vendors like
> > NVidia have already released customized PCIe devices exposing Virtio devices to
> > the host machines. But we are working on making the configurable PCIe devices
> > running Linux kernel to expose Virtio devices using the PCI Endpoint (EP)
> > subsystem.
> >
> > Below is the simplistic represenation of the idea with virt-net as an
> > example. But this could be extended to any supported Virtio devices:
> >
> > HOST ENDPOINT
> >
> > +-----------------------------+ +-----------------------------+
> > | | | |
> > | Linux Kernel | | Linux Kernel |
> > | | | |
> > | | | +------------------+ |
> > | | | | | |
> > | | | | Modem | |
> > | | | | | |
> > | | | +---------|--------+ |
> > | | | | |
> > | +------------------+ | | +---------|--------+ |
> > | | | | | | | |
> > | | Virt-net | | | | Virtio EPF | |
> > | | | | | | | |
> > | +---------|--------+ | | +---------|--------+ |
> > | | | | | |
> > | +---------|--------+ | | +---------|--------+ |
> > | | | | | | | |
> > | | Virtio PCI | | | | PCI EP Subsystem | |
> > | | | | | | | |
> > | +---------|--------+ | | +---------|--------+ |
> > | SW | | | SW | |
> > ----------------|-------------- ----------------|--------------
> > | HW | | | HW | |
> > | +---------|--------+ | | +---------|--------+ |
> > | | | | | | | |
> > | | PCIe RC | | | | PCIe EP | |
> > | | | | | | | |
> > +-----+---------|--------+----+ +-----+---------|--------+----+
> > | |
> > | |
> > | |
> > | PCIe |
> > -----------------------------------------
> >
> > While doing so, we faced an issue due to lack of MSI support defined in Virtio
> > spec for PCI transport. Currently, the PCI transport (starting from 0.9.5) has
> > only defined INTx (legacy) and MSI-X interrupts for the device to send
> > notifications to the guest. While it works well for the hypervisor to guest
> > communcation, when a physical PCIe device is used as a Virtio device, lack of
> > MSI support is hurting the performance (when there is no MSI-X).
> >
> > Most of the physical PCIe endpoint devices support MSI interrupts over MSI-X for
> > simplicity and with Virtio not supporting MSI, falling back to legacy INTx
> > interrupts is affecting the performance.
> >
> > First of all, INTx requires the PCIe devices to send two MSG TLPs
> > (Assert/Deassert) to emulate level triggered interrupt on the host. And there
> > could be some delay between assert and deassert messages to make sure that the
> > host recognizes it as an interrupt (level trigger). Also, the INTx interrupts
> > are limited to 1 per function, so all the notifications from device has to share
> > this single interrupt (INTA).
> >
> > On the other hand, MSI requires only one MWr TLP from the device to host and
> > since it is a posted write, there is no delay involved. Also, a single PCIe
> > function can use upto 32 MSIs, thus making it possible to use one MSI vector per
> > virtqueue (32 is more than enough for most of the usecases).
> >
> > So my question is, why does the Virtio spec not supporting MSI? If there are no
> > major blocker in supporting MSI, could we propose adding MSI to the Virtio spec?
> >
> > - Mani
> >
> > --
> > மணிவண்ணன் சதாசிவம்
>
> Yes, it's possible to add - however, you also said EP requires more
> changes from virtio. So maybe we need "virtio over EP" then.
I don't think we need a separate 'Virtio over EP'. EP uses PCI transport, so
'Virtio over PCI' is fine as it is. Just because 'Virtio over PCI' was designed
based on virtual PCI devices exposed by the hypervisor, the real world
limitations were not taken into account. And that's what we are trying to add.
> Let's try to figure out the full list of issues, to see which makes
> more sense.
>
Sure. But each one would need a separate discussion, that's why I started this
thread for MSI. Let me check with Shunsuke and come up with an exhaustive list.
- Mani
--
மணிவண்ணன் சதாசிவம்
prev parent reply other threads:[~2024-06-25 9:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 16:19 MSI for Virtio PCI transport Manivannan Sadhasivam
2024-06-25 4:09 ` Parav Pandit
2024-06-25 5:43 ` Manivannan Sadhasivam
2024-06-25 6:18 ` Parav Pandit
2024-06-25 7:55 ` Michael S. Tsirkin
2024-06-25 8:00 ` Parav Pandit
2024-06-25 8:09 ` Michael S. Tsirkin
2024-06-25 8:18 ` Parav Pandit
2024-06-25 8:29 ` Michael S. Tsirkin
2024-06-25 9:11 ` Manivannan Sadhasivam
2024-06-25 9:59 ` Parav Pandit
2024-06-25 7:52 ` Michael S. Tsirkin
2024-06-25 9:19 ` Manivannan Sadhasivam [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240625091911.GD2642@thinkpad \
--to=manisadhasivam.linux@gmail.com \
--cc=mie@igel.co.jp \
--cc=mst@redhat.com \
--cc=virtio-comment@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox