mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"jgg@nvidia.com" <jgg@nvidia.com>,
	"yishaih@nvidia.com" <yishaih@nvidia.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
	"darwi@linutronix.de" <darwi@linutronix.de>,
	"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>
Subject: Re: [PATCH V4 10/11] vfio/pci: Support dynamic MSI-X
Date: Fri, 28 Apr 2023 11:35:09 -0700	[thread overview]
Message-ID: <296ec21f-fc7d-eaf2-484c-27ae8815c5a8@intel.com> (raw)
In-Reply-To: <BN9PR11MB5276B67702AACB0B5BF1EC0A8C6B9@BN9PR11MB5276.namprd11.prod.outlook.com>

Hi Kevin,

On 4/27/2023 11:50 PM, Tian, Kevin wrote:
>> From: Chatre, Reinette <reinette.chatre@intel.com>
>> Sent: Friday, April 28, 2023 1:36 AM
>>
>> pci_msix_alloc_irq_at() enables an individual MSI-X interrupt to be
>> allocated 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.
>>
>> The PCI-MSIX API requires that some number of irqs are allocated for
>> an initial set of vectors when enabling MSI-X on the device. When
>> dynamic MSIX allocation is not supported, the vector table, and thus
>> the allocated irq set can only be resized by disabling and re-enabling
>> MSI-X with a different range. In that case the irq allocation is
>> essentially a cache for configuring vectors within the previously
>> allocated vector range. When dynamic MSI-X allocation is supported,
>> the API still requires some initial set of irqs to be allocated, but
>> also supports allocating and freeing specific irq vectors both
>> within and beyond the initially allocated range.
>>
>> For consistency between modes, as well as to reduce latency and improve
>> reliability of allocations, and also simplicity, this implementation
>> only releases irqs via pci_free_irq_vectors() when either the interrupt
>> mode changes or the device is released.
> 
> It improves the reliability of allocations from the calling device p.o.v.
> 
> But system-wide this is not efficient use of irqs and not releasing them
> timely may affect the reliability of allocations for other devices.

Could you please elaborate how other devices may be impacted?

> Should this behavior be something configurable?

This is not clear to me and I look to you for guidance here. From practical
side it looks like configuration via module parameters is supported but
whether it should be done is not clear to me.

When considering this we need to think about what the user may expect when
turning on/off the configuration. For example, MSI-X continues to allocate a
range of interrupts during enabling. These have always been treated as a
"cache" (interrupts remain allocated, whether they have an associated trigger
or not). If there is new configurable behavior, do you expect that the
driver needs to distinguish between the original "cache" that the user is
used to and the new dynamic allocations? That is, should a dynamic MSI-X
capable device always free interrupts when user space removes an eventfd
or should only interrupts that were allocated dynamically be freed dynamically?

>> +/*
>> + * Return Linux IRQ number of an MSI or MSI-X device interrupt vector.
>> + * If a Linux IRQ number is not available then a new interrupt will be
>> + * allocated if dynamic MSI-X is supported.
>> + */
>> +static int vfio_msi_alloc_irq(struct vfio_pci_core_device *vdev,
>> +			      unsigned int vector, bool msix)
>> +{
>> +	struct pci_dev *pdev = vdev->pdev;
>> +	struct msi_map map;
>> +	int irq;
>> +	u16 cmd;
>> +
>> +	irq = pci_irq_vector(pdev, vector);
>> +	if (irq > 0 || !msix || !vdev->has_dyn_msix)
>> +		return irq;
> 
> if (irq >= 0 || ...)
> 

I am not sure about this request because pci_irq_vector() cannot return 0.
The Linux interrupt number will be > 0 on success. 0 means "not found"
(see msi_get_virq()), which is translated to -EINVAL by pci_irq_vector().

>> +
>> +/*
>> + * Where is vfio_msi_free_irq() ?
>> + *
>> + * Allocated interrupts are maintained, essentially forming a cache that
>> + * subsequent allocations can draw from. Interrupts are freed using
>> + * pci_free_irq_vectors() when MSI/MSI-X is disabled.
>> + */
> 
> Probably merge it with the comment of vfio_msi_alloc_irq()?

Sure, will do.

> 
>> @@ -401,6 +430,12 @@ static int vfio_msi_set_vector_signal(struct
>> vfio_pci_core_device *vdev,
>>  	if (fd < 0)
>>  		return 0;
>>
>> +	if (irq == -EINVAL) {
>> +		irq = vfio_msi_alloc_irq(vdev, vector, msix);
>> +		if (irq < 0)
>> +			return irq;
>> +	}
>> +
>>  	ctx = vfio_irq_ctx_alloc(vdev, vector);
>>  	if (!ctx)
>>  		return -ENOMEM;
> 
> This doesn't read clean that an irq is allocated but not released
> in the error unwind.

I can add a comment similar to the location where the trigger is released:
	/* Interrupt stays allocated, will be freed at MSI-X disable. */

Reinette



  reply	other threads:[~2023-04-28 18:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-27 17:35 [PATCH V4 00/11] vfio/pci: Support dynamic allocation of MSI-X interrupts Reinette Chatre
2023-04-27 17:35 ` [PATCH V4 01/11] vfio/pci: Consolidate irq cleanup on MSI/MSI-X disable Reinette Chatre
2023-04-28  6:28   ` Tian, Kevin
2023-04-27 17:35 ` [PATCH V4 02/11] vfio/pci: Remove negative check on unsigned vector Reinette Chatre
2023-04-28  6:29   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 03/11] vfio/pci: Prepare for dynamic interrupt context storage Reinette Chatre
2023-04-28  6:33   ` Tian, Kevin
2023-04-28 18:24     ` Reinette Chatre
2023-05-05  7:21       ` Tian, Kevin
2023-05-08 22:52         ` Reinette Chatre
2023-04-27 17:36 ` [PATCH V4 04/11] vfio/pci: Move to single error path Reinette Chatre
2023-04-28  6:34   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 05/11] vfio/pci: Use xarray for interrupt context storage Reinette Chatre
2023-04-28  6:35   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 06/11] vfio/pci: Remove interrupt context counter Reinette Chatre
2023-04-28  6:36   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 07/11] vfio/pci: Update stale comment Reinette Chatre
2023-04-28  6:42   ` Tian, Kevin
2023-04-28 18:24     ` Reinette Chatre
2023-04-27 17:36 ` [PATCH V4 08/11] vfio/pci: Use bitfield for struct vfio_pci_core_device flags Reinette Chatre
2023-04-28  6:43   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 09/11] vfio/pci: Probe and store ability to support dynamic MSI-X Reinette Chatre
2023-04-28  6:43   ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 10/11] vfio/pci: Support " Reinette Chatre
2023-04-28  6:50   ` Tian, Kevin
2023-04-28 18:35     ` Reinette Chatre [this message]
2023-05-05  8:10       ` Tian, Kevin
2023-05-05 15:28         ` Alex Williamson
2023-05-06  8:15           ` Tian, Kevin
2023-05-05 17:21         ` Reinette Chatre
2023-05-06  8:13           ` Tian, Kevin
2023-04-27 17:36 ` [PATCH V4 11/11] vfio/pci: Clear VFIO_IRQ_INFO_NORESIZE for MSI-X Reinette Chatre
2023-04-28  6:50   ` Tian, Kevin

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=296ec21f-fc7d-eaf2-484c-27ae8815c5a8@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®