[PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Xincheng Zhang]

The VIA VL805 XHCI controller (Device ID 0x3483) fails to handle DMA
addresses correctly when they exceed 0x1000000000 (64GB). On systems
with large amounts of RAM, this hardware limitation causes device failures.

Add the XHCI_NO_64BIT_SUPPORT quirk to restrict DMA addressing to 32-bit,
preventing the controller from receiving addresses beyond its hardware
limit.

Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com>
---
 drivers/usb/host/xhci-pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 039c26b241d0..99c2dc3cebfe 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -448,6 +448,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 	if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == PCI_DEVICE_ID_VIA_VL805) {
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_TRB_OVERFETCH;
+		xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
 	}
 
 	if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&

---
base-commit: 502d801f0ab03e4f32f9a33d203154ce84887921
change-id: 20260623-xhci-via-dma-fix-c563b889ea54

Best regards,
--  
Xincheng Zhang <zhangxincheng@ultrarisc.com>

Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Michal Pecio]

On Tue, 23 Jun 2026 15:32:02 +0800, Xincheng Zhang wrote:
> The VIA VL805 XHCI controller (Device ID 0x3483) fails to handle DMA
> addresses correctly when they exceed 0x1000000000 (64GB). On systems
> with large amounts of RAM, this hardware limitation causes device
> failures.
> 
> Add the XHCI_NO_64BIT_SUPPORT quirk to restrict DMA addressing to
> 32-bit, preventing the controller from receiving addresses beyond its
> hardware limit.
> 
> Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com>

It could make sense to put a fix for this in stable too.

But I don't like this abuse of the quirk. Firstly, it causes
unnecessary bouncing on systems with >4GB RAM and no IOMMU.
I found other drivers that use DMA_BIT_MASK(36) or even weirder
numbers, so it seems that we too could request 64 gigs exactly
with a bit of driver refactoring.

Secondly, it makes the driver pretend that AC64 capability is absent.
Differences go beyond address bits, notably including register width
and whether QWORD or only DWORD writes cane be used. For example, if
we want to improve command abort on AC64 chips using QWORD writes, we
will need to know the true state of this capability, regarless of
whether the chip really implements all 64 address bits or not.

Forest, you have added a number of similar quirks for ASMedia chips.
Do you happen to know what is their real address width? I think it
might prove useful to have this on record.

Regards,
Michal

Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Xincheng Zhang]

Hi Michal,

On 2026-06-23 12:18 +0200, Michal Pecio wrote:
> But I don't like this abuse of the quirk. Firstly, it causes
> unnecessary bouncing on systems with >4GB RAM and no IOMMU.
> I found other drivers that use DMA_BIT_MASK(36) or even weirder
> numbers, so it seems that we too could request 64 gigs exactly
> with a bit of driver refactoring.

Thanks for the review. I totally agree that using `DMA_BIT_MASK(36)` is
a much better approach to avoid bounce buffers and register width issues. 

I will prepare a v2 patch with this refactoring. I'll wait a bit for
Forest's input on the ASMedia chips before sending it out, just in case 
we need to handle them together.

Thanks,
Xincheng

Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Xincheng Zhang]

Hi Michal,

On 2026-06-23 12:18 +0200, Michal Pecio wrote:
> But I don't like this abuse of the quirk. Firstly, it causes
> unnecessary bouncing on systems with >4GB RAM and no IOMMU.
> I found other drivers that use DMA_BIT_MASK(36) or even weirder
> numbers, so it seems that we too could request 64 gigs exactly
> with a bit of driver refactoring.

Thanks for the review. I totally agree that using `DMA_BIT_MASK(36)` is
a much better approach to avoid bounce buffers and register width issues. 

I will prepare a v2 patch with this refactoring. I'll wait a bit for
Forest's input on the ASMedia chips before sending it out, just in case 
we need to handle them together.

Thanks,
Xincheng

Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Michal Pecio]

On Wed, 24 Jun 2026 15:06:12 +0800, Xincheng Zhang wrote:
> Hi Michal,
> 
> On 2026-06-23 12:18 +0200, Michal Pecio wrote:
> > But I don't like this abuse of the quirk. Firstly, it causes
> > unnecessary bouncing on systems with >4GB RAM and no IOMMU.
> > I found other drivers that use DMA_BIT_MASK(36) or even weirder
> > numbers, so it seems that we too could request 64 gigs exactly
> > with a bit of driver refactoring.  
> 
> Thanks for the review. I totally agree that using `DMA_BIT_MASK(36)`
> is a much better approach to avoid bounce buffers and register width
> issues.

By the way, are you sure that 64GB is the magic number and not 1TB?
I booted a common AMD64 box with iommu.forcedac=1 and instantly got
IOMMU faults, but the addresses were truncated to 40 bits, not 36.

I applied 40 bit DMA mask and my VL805 seems to work. I looked into
debugfs and many things are mapped close to 1TB, so I wonder if some
chips are better than others or maybe there are particular workloads
where VL805 truncates something to 36 bits? I tried a few, including
bulk, interrupt, isochronous and USB3 bulk streams.

How was this problem found? Do you have >64GB RAM and no IOMMU?
Or with IOMMU whose driver allocates mappings above 4GB?

Regards,
Michal

Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805

[Xincheng Zhang]

On 2026-06-25 02:04 +0200, Michal Pecio wrote:
> By the way, are you sure that 64GB is the magic number and not 1TB?
> I booted a common AMD64 box with iommu.forcedac=1 and instantly got
> IOMMU faults, but the addresses were truncated to 40 bits, not 36.
> 
> I applied 40 bit DMA mask and my VL805 seems to work. I looked into
> debugfs and many things are mapped close to 1TB, so I wonder if some
> chips are better than others or maybe there are particular workloads
> where VL805 truncates something to 36 bits? I tried a few, including
> bulk, interrupt, isochronous and USB3 bulk streams.
> 
> How was this problem found? Do you have >64GB RAM and no IOMMU?
> Or with IOMMU whose driver allocates mappings above 4GB?

Hi Michal,

Thanks for testing this.

I re-tested this on our side and collected more details. The machine is an
UltraRISC DP1000 riscv64 system with a VIA VL805/806 controller:

  0002:01:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller [1106:3483] (rev 01)

The booted kernel was built with xHCI debug enabled and with the VL805
XHCI_NO_64BIT_SUPPORT quirk removed, so the controller was allowed to use
the normal AC64/64-bit DMA path.

This is a no-IOMMU setup, and the command line does not include
iommu.forcedac.

The system has about 64 GB of RAM:

  MemTotal:       65837388 kB

With the 64-bit DMA path enabled, xHCI setup logged DMA addresses above
0x1000000000:

  xhci_hcd 0002:01:00.0: Enabling 64-bit DMA addresses.
  xhci_hcd 0002:01:00.0: // Device context base array address = 0x0x0000001075cef000 (DMA), (____ptrval____) (virt)
  xhci_hcd 0002:01:00.0: First segment DMA is 0x0x0000000108961000
  xhci_hcd 0002:01:00.0: ERST deq = 64'h1075ca7000
  xhci_hcd 0002:01:00.0: Slot 1 output ctx = 0x0x0000001075387000 (dma)
  xhci_hcd 0002:01:00.0: Output Context DMA address = 0x1075387000

Shortly afterwards the controller stopped responding:

  xhci_hcd 0002:01:00.0: Command timeout, USBSTS: 0x00000000
  xhci_hcd 0002:01:00.0: Command timeout
  xhci_hcd 0002:01:00.0: Abort command ring
  xhci_hcd 0002:01:00.0: Abort failed to stop command ring: -110
  xhci_hcd 0002:01:00.0: Host halt failed, -110
  xhci_hcd 0002:01:00.0: xHCI host controller not responding, assume dead
  xhci_hcd 0002:01:00.0: HC died; cleaning up
  xhci_hcd 0002:01:00.0: Timeout while waiting for setup device command

With the 36-bit DMA mask applied earlier, the same controller initialized
and enumerated normally on this machine.

> By the way, are you sure that 64GB is the magic number and not 1TB?
> [...] the addresses were truncated to 40 bits, not 36.

I'm not claiming 64 GB is a hard architectural limit for all VL805/806
parts. On this particular controller (rev 01), the failing addresses
(e.g. 0x1075cef000) are only just above the 64 GiB / 36-bit boundary but
well within 40 bits, and the controller still died. So the effective limit
on this part appears to be lower than the 40 bits you observed.

> I applied 40 bit DMA mask and my VL805 seems to work. [...] so I wonder if
> some chips are better than others [...]

That matches my suspicion - this looks like it may be silicon/revision
dependent. Your part tolerating ~1 TB with a 40-bit mask while mine fails
just above 36 bits is a strong hint that the two chips behave differently.

> How was this problem found? Do you have >64GB RAM and no IOMMU?
> Or with IOMMU whose driver allocates mappings above 4GB?

The former: this box has ~64 GB of RAM and no IOMMU, so the buffers are
simply placed at their real physical addresses, some of which fall above
0x1000000000 (64 GiB). There is no IOMMU and no forcedac involved here.

One practical limitation on my side: this DP1000 only has 64 GB of RAM, so I
cannot generate physical addresses above the 40-bit range at all, and
without an IOMMU I have no way to force higher addresses either. That means
I can't bisect the real upper boundary (37/38/39/40 bits) on this hardware -
the most I can observe is that the failure already happens just above 36
bits.

Given that 36 bits is the only value I can reliably verify fixes the hang on
real hardware here, I'd lean towards keeping it as a conservative default
unless we can establish that a higher mask is safe across revisions.

Regards,
Xincheng