From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Atheros WiFi - memory paging failure on driver load Date: Mon, 18 Jul 2016 19:22:30 +0100 Message-ID: <0c92a378-5b11-034c-4ef6-ad619357d12e@citrix.com> References: <564e4c11-c19b-f250-8e75-99c70bd22ba2@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1500480141047602163==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrey Grodzovsky Cc: Jan Beulich , =?UTF-8?Q?J=c3=bcrgen_Walter_=e2=80=a2_Quattru?= , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1500480141047602163== Content-Type: multipart/alternative; boundary="------------98E56CEAA8FD787C5FF10C67" --------------98E56CEAA8FD787C5FF10C67 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 18/07/16 04:29, Andrey Grodzovsky wrote: > > > On Fri, Jul 15, 2016 at 11:45 PM, Andrey Grodzovsky > > wrote: > > > > On Fri, Jul 15, 2016 at 6:04 AM, Andrew Cooper > > wrote: > > On 12/07/16 04:59, Andrey Grodzovsky wrote: >> Hello >> >> Some background - >> >> We are trying to run Qualcomm Atheros AR928X Wireless Network >> Adapter and have a crash right on driver load, following are >> our observations and questions. >> >> Jurgen's observation - >> >> " The Atheros card "Qualcomm Atheros AR928X Wireless Network >> Adapter (PCI-Express) (rev 01)" is plugged into the host >> system (datatron). >> When I attach it to the DomU - the module "ath9k" is >> automatically loaded, but it gives an exception >> "iowrite32+0x2b/0x30". >> No idea what the issue is (tried also with another Atheros >> Card (ath10k) - similar problem). When I try an Intel card, >> it works. >> (the card also works on the Dom0 - so the Linux driver and HW >> is OK)." >> >> Debugging - >> >> After some investigation with kgdb and iommu trace on DomU it >> seems the iomap of PCI BAR for the device returns a a mapping >> f which first 0x1000 bytes are read only and that causes >> access violation when trying to write registers mapped to >> this area (all the regs with offset < 0x1000) - why this >> happens i still don't know. Register writes with offsets > >> 0x1000 are fine. > Your card is not PCI spec compliant. The Spec mandates that nothing may exist in any 4k aligned block covering part of the MSI-X table, precisely so read-only tricks like this can be done trap&intercept MSI-X updates. >> >> Running same driver on Dom0 is totally fine > This is curious. Dom0 and DomU should be treated identically in this regard. ~Andrew --------------98E56CEAA8FD787C5FF10C67 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 18/07/16 04:29, Andrey Grodzovsky wrote:


On Fri, Jul 15, 2016 at 11:45 PM, Andrey Grodzovsky <andrey2805@gmail.com> wrote:


On Fri, Jul 15, 2016 at 6:04 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
On 12/07/16 04:59, Andrey Grodzovsky wrote:
Hello

Some background -

We are trying to run Qualcomm Atheros AR928X Wireless Network Adapter and have a crash right on driver load, following are our observations and questions.

Jurgen's observation - 

" The Atheros card "Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01)"  is plugged into the host system (datatron).
When I attach it to the DomU - the module "ath9k" is automatically loaded, but it gives an exception "iowrite32+0x2b/0x30".
No idea what the issue is (tried also with another Atheros Card (ath10k) - similar problem). When I try an Intel card, it works.
(the card also works on the Dom0 - so the Linux driver and HW is OK)."

Debugging - 

After some investigation with kgdb and iommu trace on DomU it seems the iomap of PCI BAR for the device returns a a mapping f which first 0x1000 bytes are read only and that causes access violation when trying to write registers mapped to this area (all the regs with offset < 0x1000) - why this happens i still don't know. Register writes with offsets > 0x1000 are fine.

Your card is not PCI spec compliant.

The Spec mandates that nothing may exist in any 4k aligned block covering part of the MSI-X table, precisely so read-only tricks like this can be done trap&intercept MSI-X updates.




Running same driver on Dom0 is totally fine

This is curious.  Dom0 and DomU should be treated identically in this regard.

~Andrew
--------------98E56CEAA8FD787C5FF10C67-- --===============1500480141047602163== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1500480141047602163==--