From: Jason Gunthorpe <jgg@ziepe.ca>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
kvm@vger.kernel.org, quic_bqiang@quicinc.com, kvalo@kernel.org,
prestwoj@gmail.com, linux-wireless@vger.kernel.org,
ath11k@lists.infradead.org, dwmw2@infradead.org,
iommu@lists.linux.dev, kernel@quicinc.com,
johannes@sipsolutions.net, jtornosm@redhat.com
Subject: Re: [PATCH RFC/RFT] vfio/pci: Create feature to disable MSI virtualization
Date: Wed, 14 Aug 2024 12:20:25 -0300 [thread overview]
Message-ID: <20240814152025.GA3468552@ziepe.ca> (raw)
In-Reply-To: <20240814085505.60819623.alex.williamson@redhat.com>
On Wed, Aug 14, 2024 at 08:55:05AM -0600, Alex Williamson wrote:
> Let's imagine the guest driver does change to implement an irq_domain.
> How does that fundamentally change the problem for the VMM that guest
> MSI values are being written to other portions of the device?
If changed to irq_domain the VM will write addr/data pairs into those
special register that are unique to that interrupt source and will not
re-use values already set in the MSI table.
This means the VMM doesn't get any value from inspecting the MSI table
because the value it needs won't be there, and alos that no interrupt
routing will have been setup. The VMM must call VFIO_DEVICE_SET_IRQS
to setup the unique routing.
These two patches are avoiding VFIO_DEVICE_SET_IRQS based on the
assumption that the VM will re-use a addr/data pair already setup in
the MSI table. Invalidating that assumption is the fundamental change
irq_domain in the VM will make.
> The guest driver can have whatever architecture it wants (we don't
> know the architecture of the Windows driver) but we still need to
> trap writes of the guest MSI address/data and replace it with host
> values.
Yes you do. But the wrinkle is you can't just assume one of the
existing MSI entries is a valid replacement and copy from the MSI
table. That works right now only because the Linux/Windows driver is
re-using a MSI vector in the IMS registers.
I suggest the general path is something like:
1) A vfio variant driver sets up an irq_domain for the additional
interrupt source registers
2) Somehow wire up VFIO_DEVICE_SET_IRQS so it can target vectors in
the additional interrupt domain
3) Have the VMM trap writes to the extra interrupt source registers
and execute VFIO_DEVICE_SET_IRQS
4) IRQ layer will setup an appropriate unique IRQ and route it to the
guest/whatever just like MSI. Callbacks into the variant driver's
irq_domain will program the HW registers.
Basically exactly the same flow as MSI, except instead of targetting a
vector in the PCI core's MSI irq_domain it targets a vector in the
variant driver's IMS IRQ domain.
Then we don't make any assumptions about how the VM is using these
interrupt vectors, and crucially, SET_IRQs is called for every
interrupt source and we rely on the kernel to produce the correct
addr/data pair. No need for copying addr/data pairs from MSI tables.
> As noted above, this does not provide any visible change to a QEMU
> guest, it only enables QEMU to implement the quirk in the other
> patch.
I see, I definitely didn't understand that it only reaches qemu from
the commit message..
Jason
next prev parent reply other threads:[~2024-08-14 15:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <adcb785e-4dc7-4c4a-b341-d53b72e13467@gmail.com>
2024-08-12 16:59 ` [PATCH RFC/RFT] vfio/pci: Create feature to disable MSI virtualization Alex Williamson
2024-08-13 16:30 ` Jason Gunthorpe
2024-08-13 17:30 ` Thomas Gleixner
2024-08-13 23:39 ` Jason Gunthorpe
2024-12-13 9:10 ` David Woodhouse
2025-01-03 14:31 ` Jason Gunthorpe
2025-01-03 14:47 ` David Woodhouse
2025-01-03 15:19 ` Jason Gunthorpe
2024-08-13 21:14 ` Alex Williamson
2024-08-13 23:16 ` Jason Gunthorpe
2024-08-14 14:55 ` Alex Williamson
2024-08-14 15:20 ` Jason Gunthorpe [this message]
2024-08-12 17:00 ` [PATCH RFC/RFT] vfio/pci-quirks: Quirk for ath wireless Alex Williamson
2024-08-13 16:43 ` Jason Gunthorpe
2024-08-13 21:03 ` Alex Williamson
2024-08-13 23:37 ` Jason Gunthorpe
2024-08-15 16:59 ` Alex Williamson
2024-08-15 17:19 ` Jason Gunthorpe
2026-03-16 14:58 ` James Prestwood
2026-03-16 15:43 ` James Prestwood
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=20240814152025.GA3468552@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex.williamson@redhat.com \
--cc=ath11k@lists.infradead.org \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=johannes@sipsolutions.net \
--cc=jtornosm@redhat.com \
--cc=kernel@quicinc.com \
--cc=kvalo@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=prestwoj@gmail.com \
--cc=quic_bqiang@quicinc.com \
--cc=tglx@linutronix.de \
/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