From: Alex Williamson <alex.williamson@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Chatre, Reinette" <reinette.chatre@intel.com>,
"jgg@nvidia.com" <jgg@nvidia.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: Wed, 1 Nov 2023 12:07:14 -0600 [thread overview]
Message-ID: <20231101120714.7763ed35.alex.williamson@redhat.com> (raw)
In-Reply-To: <BL1PR11MB52710EAB683507AD7FAD6A5B8CA0A@BL1PR11MB5271.namprd11.prod.outlook.com>
On Tue, 31 Oct 2023 07:31:24 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:
> > From: Chatre, Reinette <reinette.chatre@intel.com>
> > Sent: Saturday, October 28, 2023 1:01 AM
> >
> > Changes since RFC V2:
> > - RFC V2:
> > https://lore.kernel.org/lkml/cover.1696609476.git.reinette.chatre@intel.com
> > /
> > - Still submiting this as RFC series. I believe that this now matches the
> > expectatations raised during earlier reviews. If you agree this is
> > the right direction then I can drop the RFC prefix on next submission.
> > If you do not agree then please do let me know where I missed
> > expectations.
>
> Overall this matches my expectation. Let's wait for Alex/Jason's thoughts
> before moving to next-level refinement.
It feels like there's a lot of gratuitous change without any clear
purpose. We create an ops structure so that a variant/mdev driver can
make use of the vfio-pci-core set_irqs ioctl piecemeal, but then the
two entry points that are actually implemented by the ims version are
the same as the core version, so the ops appear to be at the wrong
level. The use of the priv pointer for the core callbacks looks like
it's just trying to justify the existence of the opaque pointer, it
should really just be using container_of(). We drill down into various
support functions for MSI (ie. enable, disable, request_interrupt,
free_interrupt, device name), but INTx is largely ignored, where we
haven't even kept is_intx() consistent with the other helpers.
Without an in-tree user of this code, we're just chopping up code for
no real purpose. There's no reason that a variant driver requiring IMS
couldn't initially implement their own SET_IRQS ioctl. Doing that
might lead to a more organic solution where we create interfaces where
they're actually needed. The existing mdev sample drivers should also
be considered in any schemes to refactor the core code into a generic
SET_IRQS helper for devices exposing a vfio-pci API. Thanks,
Alex
next prev parent reply other threads:[~2023-11-01 18:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 17:00 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 [this message]
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
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=20231101120714.7763ed35.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=dave.jiang@intel.com \
--cc=fenghua.yu@intel.com \
--cc=jgg@nvidia.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
all inboxes | Powered by JetHome®