qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Cc: clg@redhat.com, vaibhav@linux.ibm.com, npiggin@gmail.com,
	harshpb@linux.ibm.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] vfio/pci: Skip enabling INTx if the IRQ line is also unassgined
Date: Fri, 31 Jan 2025 15:02:01 -0700	[thread overview]
Message-ID: <20250131150201.048aa3bf.alex.williamson@redhat.com> (raw)
In-Reply-To: <173834353589.1880.3587671276264097972.stgit@linux.ibm.com>

On Fri, 31 Jan 2025 17:15:01 +0000
Shivaprasad G Bhat <sbhat@linux.ibm.com> wrote:

> Currently, the PCI_INTERRUPT_PIN alone is checked before enabling
> the INTx. Its also necessary to have the IRQ Lines assigned for
> the INTx to work. So, check the PCI_INTERRUPT_LINE against 0xff
> indicates no connection.
> 
> The problem was observed on Power10 systems which primarily use
> MSI-X, and LSI lines are not connected on all devices under a
> PCIe switch. In this configuration where the PIN is non-zero
> but the LINE was 0xff, the VFIO_DEVICE_SET_IRQS was failing as
> it was trying to map the irqfd for the LSI of the device.
> 
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> ---
>  hw/vfio/pci.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index ab17a98ee5..69a519d143 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -264,12 +264,12 @@ static void vfio_irqchip_change(Notifier *notify, void *data)
>  static bool vfio_intx_enable(VFIOPCIDevice *vdev, Error **errp)
>  {
>      uint8_t pin = vfio_pci_read_config(&vdev->pdev, PCI_INTERRUPT_PIN, 1);
> +    uint8_t line = vfio_pci_read_config(&vdev->pdev, PCI_INTERRUPT_LINE, 1);
>      Error *err = NULL;
>      int32_t fd;
>      int ret;
>  
> -
> -    if (!pin) {
> +    if (!pin || (line == 0xFF)) {
>          return true;
>      }
>  

vfio_intx_enable() should be the backup that catches users trying to
configure INTx, but we should also be indicating there's no INTx
through the IRQ_INFO ioctl.  The value in the line register is also not
defined by the PCI spec, it's implementation specific, therefore for
what architectures is this interpretation of the line register valid?

Should we at the same time virtualize the pin register as zero?

Maybe it's also time to implement similar checking for dev->irq ==
IRQ_NOTCONNECTED.  Do Power systems make use of the IRQ_NOTCONNECTED
convention?  Thanks,

Alex



  reply	other threads:[~2025-01-31 22:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31 17:15 [PATCH] vfio/pci: Skip enabling INTx if the IRQ line is also unassgined Shivaprasad G Bhat
2025-01-31 22:02 ` Alex Williamson [this message]
2025-03-18 17:56   ` Shivaprasad G Bhat

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=20250131150201.048aa3bf.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=harshpb@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=sbhat@linux.ibm.com \
    --cc=vaibhav@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).