Received-SPF: pass (google.com: domain of linux-wireless+bounces-5113-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <55125648b2553ce746b92092a009d4939d1eb6b8.camel@sipsolutions.net>
Subject: Re: ath11k and vfio-pci support
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
Date: Thu, 21 Mar 2024 20:14:17 +0100
In-Reply-To: <57d20bd812ccf8d1a5815ad41b5dcea3925d4fe1.camel@infradead.org>
References: <adcb785e-4dc7-4c4a-b341-d53b72e13467@gmail.com>
	 <8734v5zhol.fsf@kernel.org>
	 <87fa5220-6fd9-433d-879b-c55ac67a0748@gmail.com>
	 <87r0ipcn7j.fsf@kernel.org>
	 <356e0b05-f396-4ad7-9b29-c492b54af834@gmail.com>
	 <26119c3f-9012-47bb-948e-7e976d4773a7@quicinc.com>
	 <87mstccmk6.fsf@kernel.org>
	 <df9fd970-5af3-468c-b1f1-18f91215cf44@gmail.com>
	 <8734v4auc4.fsf@kernel.org>
	 <e8878979-1f3f-4635-a716-9ac381c617d9@gmail.com>
	 <285b84d0-229c-4c83-a7d6-4c3c23139597@quicinc.com>
	 <4607fb37-8227-49a3-9e8c-10c9b117ec7b@gmail.com>
	 <3d22a730-aee5-4f2a-9ddc-b4b5bd4d62fe@quicinc.com>
	 <87il3w7zjh.fsf@kernel.org>
	 <20240115104658.0b56bd35.alex.williamson@redhat.com>
	 <543d9d2f-e132-4fdb-8454-68595cd20515@quicinc.com>
	 <57d20bd812ccf8d1a5815ad41b5dcea3925d4fe1.camel@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

Given the "ewww" patch to make a module parameter workaround for this:
https://lore.kernel.org/linux-wireless/20240321172402.346191-1-jtornosm@red=
hat.com/T/#u


On Tue, 2024-01-16 at 11:41 +0100, David Woodhouse wrote:
>=20
> 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 th=
e
> > > driver needs visibility of the physical MSI address and data.
> > >=20
>=20
> 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.=20

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