From: Johannes Berg <johannes@sipsolutions.net>
To: David Woodhouse <dwmw2@infradead.org>,
Baochen Qiang <quic_bqiang@quicinc.com>,
Alex Williamson <alex.williamson@redhat.com>,
Kalle Valo <kvalo@kernel.org>
Cc: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>,
James Prestwood <prestwoj@gmail.com>,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
iommu@lists.linux.dev
Subject: Re: ath11k and vfio-pci support
Date: Thu, 21 Mar 2024 20:14:17 +0100 [thread overview]
Message-ID: <55125648b2553ce746b92092a009d4939d1eb6b8.camel@sipsolutions.net> (raw)
In-Reply-To: <57d20bd812ccf8d1a5815ad41b5dcea3925d4fe1.camel@infradead.org>
Given the "ewww" patch to make a module parameter workaround for this:
https://lore.kernel.org/linux-wireless/20240321172402.346191-1-jtornosm@redhat.com/T/#u
On Tue, 2024-01-16 at 11:41 +0100, David Woodhouse wrote:
>
> How exactly is the content of this register then given back to the
> firmware? Is that communication snoopable by the VMM?
If I'm reading the code correctly, it's just a write to a register in a
memory mapped region, possibly in multiple locations (different queues
or something). Possibly indirect (see __ath11k_pcic_write32), but
someone would have to trace it or know the HW better to understand which
locations it's written to.
But yeah seems totally feasible to just translate that back in the VMM.
> > > Off hand I don't have a good solution for this, the hardware is
> > > essentially imposing a unique requirement for MSI programming that the
> > > driver needs visibility of the physical MSI address and data.
> > >
>
> Strictly, the driver doesn't need visibility to the actual values used
> by the hardware. Another way of it looking at it would be to say that
> the driver programs the MSI through this non-standard method, it just
> needs the VMM to trap and handle that, just as the VMM does for the
> standard MSI table.
Indeed. Much better than having a module parameter.
> Which is what I thought we'd already seen on some Atheros devices.
It probably also affects ath12k, seems similar.
johannes
next prev parent reply other threads:[~2024-03-21 19:14 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 13:17 ath11k and vfio-pci support James Prestwood
2024-01-10 9:00 ` Kalle Valo
2024-01-10 13:04 ` James Prestwood
2024-01-10 13:49 ` Kalle Valo
2024-01-10 14:55 ` James Prestwood
2024-01-11 3:51 ` Baochen Qiang
2024-01-11 8:16 ` Kalle Valo
2024-01-11 12:48 ` James Prestwood
2024-01-11 13:11 ` Kalle Valo
2024-01-11 13:38 ` James Prestwood
2024-01-12 2:04 ` Baochen Qiang
2024-01-12 12:47 ` James Prestwood
2024-01-14 12:37 ` Baochen Qiang
2024-01-14 14:36 ` Kalle Valo
2024-01-15 17:46 ` Alex Williamson
2024-01-16 10:08 ` Baochen Qiang
2024-01-16 10:41 ` David Woodhouse
2024-01-16 15:29 ` Jason Gunthorpe
2024-01-16 18:28 ` Alex Williamson
2024-01-16 21:10 ` Jeff Johnson
2024-01-17 5:47 ` Baochen Qiang
2024-03-21 19:14 ` Johannes Berg [this message]
2024-01-16 13:05 ` James Prestwood
2024-01-17 5:26 ` Baochen Qiang
2024-01-17 13:20 ` James Prestwood
2024-01-17 13:43 ` Kalle Valo
2024-01-17 14:25 ` James Prestwood
2024-01-18 2:09 ` Baochen Qiang
2024-01-19 17:52 ` James Prestwood
2024-01-19 17:57 ` Kalle Valo
2024-01-19 18:07 ` James Prestwood
2024-01-26 18:20 ` James Prestwood
2024-01-27 4:31 ` Baochen Qiang
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
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
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=55125648b2553ce746b92092a009d4939d1eb6b8.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alex.williamson@redhat.com \
--cc=ath11k@lists.infradead.org \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jtornosm@redhat.com \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=prestwoj@gmail.com \
--cc=quic_bqiang@quicinc.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).