All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: sashiko-bot@kernel.org
Cc: jtornosm@redhat.com, kvm@vger.kernel.org,
	linux-pci@vger.kernel.org, sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH 5/7] ath11k: Use VFIO MSI cache when available
Date: Sun, 11 Oct 2026 09:36:53 +0200	[thread overview]
Message-ID: <20261011073653.508592-1-jtornosm@redhat.com> (raw)
In-Reply-To: <20260930150856.8ED211F00898@smtp.kernel.org>

> [Severity: Low]
> Does this unconditional linear scan of the extended configuration space risk
> unintended hardware side effects?
>
> Calling qcom_vfio_find_msi_cache() loops over the entire extended
> configuration space reading 4 bytes at a time instead of using the standard
> PCIe capability linked-list traversal.
>
> This could trigger side effects if there are clear-on-read registers present
> in the configuration space.

Not applicable. qcom_vfio_find_msi_cache() is a VM-side function:
config reads go through QEMU's VFIO config space virtualization layer,
not directly to hardware. No URs or read side-effects will occur.

> [Severity: High]
> Will this host physical MSI data be unconditionally overwritten later during
> the probe sequence?
>
> After ath11k_pci_alloc_msi() correctly sets ab->pci.msi.ep_base_data from the
> VFIO cache, the probe sequence in ath11k_pci_probe() continues.
>
> Later, ath11k_pci_probe() calls ath11k_pci_config_msi_data() which does this:
>
> ath11k_pci_config_msi_data() {
>         ...
>         ab_pci->ab->pci.msi.ep_base_data = msi_desc->msg.data;
> }
>
> This appears to overwrite the host MSI data retrieved from the VFIO cache
> with the guest virtual MSI data, which could break interrupt delivery in VMs.

Valid concern. Although ep_base_data is always zero in practice with
interrupt remapping (both host and guest values are zero), the overwrite
is technically incorrect and could be a bug if the data value is ever
non-zero. Fixed in v2 by guarding config_msi_data() to skip the
overwrite when VFIO cached values are already set.

> [Severity: Medium]
> Does returning early here skip ath11k_pci_msi_disable() and leave the device
> in an inconsistent initialization state compared to the bare-metal path?
>
> By bypassing the ath11k_pci_msi_disable(ab_pci) call just below, the device
> is left with MSI enabled prematurely in the PCI configuration space.

Intentional. In the VFIO VM path, MSI is already configured by QEMU
through the host vfio-pci driver. The device MSI state is managed by
the host, so disabling and re-enabling MSI in the guest is not needed
and would interfere with the host setup.

Will send v2 with fix for findings.


  reply	other threads:[~2026-10-11  7:37 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 14:08 [PATCH 0/7] Enable Qualcomm WiFi PCIe passthrough to VMs Jose Ignacio Tornos Martinez
2026-09-30 14:08 ` [PATCH 1/7] PCI: Add pci_find_free_ext_cap_offset() helper Jose Ignacio Tornos Martinez
2026-09-30 14:21   ` sashiko-bot
2026-10-11  7:16     ` Jose Ignacio Tornos Martinez
2026-09-30 14:08 ` [PATCH 2/7] vfio: Add qcom_vfio.h header for MSI cache protocol Jose Ignacio Tornos Martinez
2026-09-30 14:31   ` sashiko-bot
2026-10-11  7:17     ` Jose Ignacio Tornos Martinez
2026-09-30 14:08 ` [PATCH 3/7] vfio/pci: Add qcom-vfio-pci variant driver Jose Ignacio Tornos Martinez
2026-09-30 14:45   ` sashiko-bot
2026-10-11  7:32     ` Jose Ignacio Tornos Martinez
2026-09-30 15:12   ` Jason Gunthorpe
2026-10-01  7:19     ` Jose Ignacio Tornos Martinez
2026-10-02 17:10       ` Jason Gunthorpe
2026-10-05 11:01         ` Jose Ignacio Tornos Martinez
2026-09-30 14:08 ` [PATCH 4/7] ath11k: add PCIe link recovery retry Jose Ignacio Tornos Martinez
2026-09-30 14:56   ` sashiko-bot
2026-10-11  7:35     ` Jose Ignacio Tornos Martinez
2026-10-14 16:58   ` Bjorn Helgaas
2026-09-30 14:08 ` [PATCH 5/7] ath11k: Use VFIO MSI cache when available Jose Ignacio Tornos Martinez
2026-09-30 15:08   ` sashiko-bot
2026-10-11  7:36     ` Jose Ignacio Tornos Martinez [this message]
2026-09-30 14:08 ` [PATCH 6/7] ath12k: add PCIe link recovery retry Jose Ignacio Tornos Martinez
2026-09-30 15:17   ` sashiko-bot
2026-10-11  7:39     ` Jose Ignacio Tornos Martinez
2026-09-30 14:08 ` [PATCH 7/7] ath12k: Use VFIO MSI cache when available Jose Ignacio Tornos Martinez
2026-09-30 15:29   ` sashiko-bot
2026-10-11  7:41     ` Jose Ignacio Tornos Martinez
2026-10-11  7:54 ` [PATCH 0/7] Enable Qualcomm WiFi PCIe passthrough to VMs Jose Ignacio Tornos Martinez
2026-10-11 13:25   ` Jason Gunthorpe
2026-10-13 13:43     ` Jose Ignacio Tornos Martinez
2026-10-13 14:03       ` Jason Gunthorpe
2026-10-13 15:42         ` Jose Ignacio Tornos Martinez
2026-10-14 15:00           ` Jason Gunthorpe

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=20261011073653.508592-1-jtornosm@redhat.com \
    --to=jtornosm@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.