mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <jgg@nvidia.com>, <yishaih@nvidia.com>,
	<shameerali.kolothum.thodi@huawei.com>, <kevin.tian@intel.com>,
	<tglx@linutronix.de>, <darwi@linutronix.de>,
	<kvm@vger.kernel.org>, <dave.jiang@intel.com>,
	<jing2.liu@intel.com>, <ashok.raj@intel.com>,
	<fenghua.yu@intel.com>, <tom.zanussi@linux.intel.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 09/10] vfio/pci: Support dynamic MSI-X
Date: Wed, 19 Apr 2023 11:13:29 -0700	[thread overview]
Message-ID: <f0d22db8-213d-92f7-963a-9d015c0a9d79@intel.com> (raw)
In-Reply-To: <20230418163829.149e8881.alex.williamson@redhat.com>

Hi Alex,

On 4/18/2023 3:38 PM, Alex Williamson wrote:
> On Tue, 18 Apr 2023 10:29:20 -0700
> Reinette Chatre <reinette.chatre@intel.com> wrote:
> 
>> Recently introduced pci_msix_alloc_irq_at() and pci_msix_free_irq()
>> enables an individual MSI-X interrupt to be allocated and freed after
>> MSI-X enabling.
>>
>> Use dynamic MSI-X (if supported by the device) to allocate an interrupt
>> after MSI-X is enabled. An MSI-X interrupt is dynamically allocated at
>> the time a valid eventfd is assigned. This is different behavior from
>> a range provided during MSI-X enabling where interrupts are allocated
>> for the entire range whether a valid eventfd is provided for each
>> interrupt or not.
>>
>> Do not dynamically free interrupts, leave that to when MSI-X is
>> disabled.
> 
> But we do, sometimes, even if essentially only on the error path.  Is
> that worthwhile?  It seems like we could entirely remove
> vfio_msi_free_irq() and rely only on pci_free_irq_vectors() on MSI/X
> teardown.

Yes, it is only on the error path where dynamic MSI-X interrupts are
removed. I do not know how to determine if it is worthwhile. On the
kernel side failure seems unlikely since it would mean memory cannot
be allocated or request_irq() failed. In these cases it may not be
worthwhile since user space may try again and having the interrupt
already allocated would be helpful. The remaining error seems to be
if user space provided an invalid eventfd. An allocation in response
to wrong user input is a concern to me. Should we consider
buggy/malicious users? I am uncertain here so would defer to your
guidance.

> I'd probably also add a comment in the commit log about the theory
> behind not dynamically freeing irqs, ie. latency, reliability, and
> whatever else we used to justify it.  Thanks,

Sure. How about something like below to replace the final sentence of
the changelog:

"When a guest disables an interrupt, user space (Qemu) does not
disable the interrupt but instead assigns it a different trigger. A
common flow is thus for the VFIO_DEVICE_SET_IRQS ioctl() to be 
used to assign a new eventfd to an already enabled interrupt. Freeing
and re-allocating an interrupt in this scenario would add unnecessary
latency as well as uncertainty since the re-allocation may fail. Do
not dynamically free interrupts when an interrupt is disabled, instead
support a subsequent re-enable to draw from the initial allocation when
possible. Leave freeing of interrupts to when MSI-X is disabled."

Reinette


  reply	other threads:[~2023-04-19 18:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 17:29 [PATCH V3 00/10] vfio/pci: Support dynamic allocation of MSI-X interrupts Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 01/10] vfio/pci: Consolidate irq cleanup on MSI/MSI-X disable Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 02/10] vfio/pci: Remove negative check on unsigned vector Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 03/10] vfio/pci: Prepare for dynamic interrupt context storage Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 04/10] vfio/pci: Move to single error path Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 05/10] vfio/pci: Use xarray for interrupt context storage Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 06/10] vfio/pci: Remove interrupt context counter Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 07/10] vfio/pci: Update stale comment Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 08/10] vfio/pci: Probe and store ability to support dynamic MSI-X Reinette Chatre
2023-04-18 22:38   ` Alex Williamson
2023-04-19 18:11     ` Reinette Chatre
2023-04-24 17:43       ` Jason Gunthorpe
2023-04-24 23:52         ` Reinette Chatre
2023-04-25 14:51           ` Jason Gunthorpe
2023-04-25 16:52             ` Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 09/10] vfio/pci: Support " Reinette Chatre
2023-04-18 22:38   ` Alex Williamson
2023-04-19 18:13     ` Reinette Chatre [this message]
2023-04-19 21:38       ` Alex Williamson
2023-04-19 22:03         ` Reinette Chatre
2023-04-18 17:29 ` [PATCH V3 10/10] vfio/pci: Clear VFIO_IRQ_INFO_NORESIZE for MSI-X Reinette Chatre
2023-04-18 22:38   ` Alex Williamson
2023-04-19 18:13     ` 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=f0d22db8-213d-92f7-963a-9d015c0a9d79@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=darwi@linutronix.de \
    --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=shameerali.kolothum.thodi@huawei.com \
    --cc=tglx@linutronix.de \
    --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®