From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"yishaih@nvidia.com" <yishaih@nvidia.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Jiang, Dave" <dave.jiang@intel.com>,
"Liu, Jing2" <jing2.liu@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Yu, Fenghua" <fenghua.yu@intel.com>,
"tom.zanussi@linux.intel.com" <tom.zanussi@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [RFC PATCH V3 00/26] vfio/pci: Back guest interrupts from Interrupt Message Store (IMS)
Date: Tue, 7 Nov 2023 22:49:53 -0400 [thread overview]
Message-ID: <20231108024953.GR4488@nvidia.com> (raw)
In-Reply-To: <20231107160641.45aee2e0.alex.williamson@redhat.com>
On Tue, Nov 07, 2023 at 04:06:41PM -0700, Alex Williamson wrote:
> A vfio-pci variant driver is specifically a driver that leverages
> portions of vfio-pci-core for implementing vfio_device_ops and binds to
> a PCI device. It might actually be the wrong term here, but I jumped
> to that since the series tries to generalize portions of one of the
> vfio-pci-core code paths. You might very well be intending to use this
> with something more like an mdev driver, which is fine.
IDXD will be a SIOV device and we need to have a serious talk about
how SIOV device lifecycle will work..
> That also sort of illustrates the point though that this series is
> taking a pretty broad approach to slicing up vfio-pci-core's SET_IRQS
> ioctl code path, enabling support for IMS backed interrupts, but in
> effect complicating the whole thing without any actual consumer to
> justify the complication. Meanwhile I think the goal is to reduce
> complication to a driver that doesn't exist yet. So it currently seems
> like a poor trade-off.
I think we need to see some draft of the IDXD driver to really
understand this
> This driver that doesn't exist yet could implement its own SET_IRQS
> ioctl that backs MSI-X with IMS as a starting point. Presumably we
> expect multiple drivers to require this behavior, so common code makes
> sense, but the rest of us in the community can't really evaluate how
> much it makes sense to slice the common code without seeing that
> implementation and how it might leverage, if not directly use, the
> existing core code.
I've been seeing a general interest in taking something that is not
MSI-X (eg "IMS" for IDXD) and converting it into MSI-X for the vPCI
function. I think this will be a durable need in this space.
Ideally it will be overtaken by simply teaching the guest, vfio and
the hypervisor interrupt logic how to directly generate interrupts
with a guest controlled addr/data pair without requiring MSI-X
trapping. That is the fundamental reason why this has to be done this
convoluted way.
Jason
next prev parent reply other threads:[~2023-11-08 2:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 17:00 [RFC PATCH V3 00/26] vfio/pci: Back guest interrupts from Interrupt Message Store (IMS) Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 01/26] PCI/MSI: Provide stubs for IMS functions Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 02/26] vfio/pci: Move PCI specific check from wrapper to PCI function Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 03/26] vfio/pci: Use unsigned int instead of unsigned Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 04/26] vfio/pci: Make core interrupt callbacks accessible to all virtual devices Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 05/26] vfio/pci: Split PCI interrupt management into front and backend Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 06/26] vfio/pci: Separate MSI and MSI-X handling Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 07/26] vfio/pci: Move interrupt eventfd to interrupt context Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 08/26] vfio/pci: Move mutex acquisition into function Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 09/26] vfio/pci: Move per-interrupt contexts to generic interrupt struct Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 10/26] vfio/pci: Move IRQ type to generic interrupt context Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 11/26] vfio/pci: Provide interrupt context to irq_is() and is_irq_none() Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 12/26] vfio/pci: Provide interrupt context to generic ops Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 13/26] vfio/pci: Provide interrupt context to vfio_msi_enable() and vfio_msi_disable() Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 14/26] vfio/pci: Let interrupt management backend interpret interrupt index Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 15/26] vfio/pci: Move generic code to frontend Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 16/26] vfio/pci: Split interrupt context initialization Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 17/26] vfio/pci: Make vfio_pci_set_irqs_ioctl() available Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 18/26] vfio/pci: Preserve per-interrupt contexts Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 19/26] vfio/pci: Store Linux IRQ number in per-interrupt context Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 20/26] vfio/pci: Separate frontend and backend code during interrupt enable/disable Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 21/26] vfio/pci: Replace backend specific calls with callbacks Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 22/26] vfio/pci: Introduce backend specific context initializer Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 23/26] vfio/pci: Support emulated interrupts Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 24/26] vfio/pci: Add core IMS support Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 25/26] vfio/pci: Add accessor for IMS index Reinette Chatre
2023-10-27 17:00 ` [RFC PATCH V3 26/26] vfio/pci: Support IMS cookie modification Reinette Chatre
2023-10-31 7:31 ` [RFC PATCH V3 00/26] vfio/pci: Back guest interrupts from Interrupt Message Store (IMS) Tian, Kevin
2023-11-01 18:07 ` Alex Williamson
2023-11-02 2:51 ` Tian, Kevin
2023-11-02 3:14 ` Tian, Kevin
2023-11-02 21:13 ` Alex Williamson
2023-11-03 7:23 ` Tian, Kevin
2023-11-03 15:51 ` Alex Williamson
2023-11-07 8:29 ` Tian, Kevin
2023-11-07 19:48 ` Reinette Chatre
2023-11-07 23:06 ` Alex Williamson
2023-11-08 2:49 ` Jason Gunthorpe [this message]
2023-11-08 9:16 ` Tian, Kevin
2023-11-08 16:52 ` Reinette Chatre
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=20231108024953.GR4488@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=dave.jiang@intel.com \
--cc=fenghua.yu@intel.com \
--cc=jing2.liu@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=reinette.chatre@intel.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tom.zanussi@linux.intel.com \
--cc=yishaih@nvidia.com \
/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