Linux USB
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Michal Pecio <michal.pecio@gmail.com>
Cc: Xincheng Zhang <zhangxincheng@ultrarisc.com>,
	cyrozap@gmail.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	mathias.nyman@intel.com
Subject: Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805
Date: Fri, 26 Jun 2026 09:06:15 +0100	[thread overview]
Message-ID: <20260626090615.616666b4@pumpkin> (raw)
In-Reply-To: <20260625191852.0a8d511c.michal.pecio@gmail.com>

On Thu, 25 Jun 2026 19:18:52 +0200
Michal Pecio <michal.pecio@gmail.com> wrote:

...
> Right, your addresses barely exceed the 36 bit limit. And I found why
> my chip behaved differently - 40 bit DMA was a firmware upgrade.
> 
> After downgrading my controller from 00013704 to 00013600 it truncates
> addresses to 36 bits and fails like yours. And it's a pretty nasty bug,
> because some of those accesses are writes to scratchpad buffers, so
> without IOMMU the chip corrupts unrelated memory below 64GB.
> 
> You can check your FW version with this one-liner:
> lspci -d 1106:3483 -xxx | awk '/^50:/ { print "VL805 FW version: " $5 $4 $3 $2 }'
> 
> More about VL805 firmwares:
> https://github.com/jpmorrison/VL805
> 
> One could ask whether 36 bits is low enough for all VL805, but I think
> it is because the bug is hard not to notice and nobody ever reported it
> on systems with less than 64 GB of RAM, even though 16 or 32 GB without
> IOMMU was a common option in DDR3 generation PCs, which is also about
> the era when this controller was introduced.

36 bits is just enough to support 32bit x86 with PAE.
Seems very short sighted.
IIRC xhci has a quite restrictive limit on address boundaries so supporting
larger addresses is just latches - there is no need for a 64bit counter.

Can you do a read-back of one of the control registers that contains
an address - if you are lucky the high bits will return zero.
That might let the generic code enforce a limit.

-- David

> 
> Regards,
> Michal
> 


  parent reply	other threads:[~2026-06-26  8:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  7:32 [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805 Xincheng Zhang
2026-06-23 10:18 ` Michal Pecio
2026-06-24  5:26   ` Xincheng Zhang
2026-06-24  7:06   ` Xincheng Zhang
2026-06-25  0:04     ` Michal Pecio
2026-06-25  2:16       ` Xincheng Zhang
2026-06-25 17:18         ` Michal Pecio
2026-06-26  2:08           ` Xincheng Zhang
2026-06-26  8:06           ` David Laight [this message]
2026-06-26  8:57             ` Michal Pecio
2026-06-26 10:55               ` David Laight

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=20260626090615.616666b4@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=cyrozap@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=michal.pecio@gmail.com \
    --cc=zhangxincheng@ultrarisc.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