linux-kernel - [RESEND PATCH] xhci: Fix Renesas PCIe controllers passthrough issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Oct 2022 18:39:14 +0800
From:   wangwenmei168@....com
To:     mathias.nyman@...el.com, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     gehao <gehao@...inos.cn>
Subject: [RESEND PATCH] xhci: Fix Renesas PCIe controllers passthrough issue

From: gehao <gehao@...inos.cn>

When we use uPD720201 USB 3.0 Host Controller passthrough to VM
guest os will report follow errors and it can not working.

xhci_hcd 0000:09:00.0: Host took too long to start, waited 16000
microseconds.
xhci_hcd 0000:09:00.0: startup error -19.

Because when we passthroug some device to our guest os,
dev->iommu_group =NULL,so it will return from this function,
Actually it still control by host os.
I think that this condition is not necessary.

For host os with IOMMU,it is safe.
For host os with noiommu,doing anything when there is no
iommu is definitely.
For guest os,the addresses we can access are restricted.

After add this path,they all work well.

Signed-off-by: gehao <gehao@...inos.cn>
---
 drivers/usb/host/xhci.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5176765c4013..e8f4c4ee3ea3 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -241,12 +241,8 @@ static void xhci_zero_64b_regs(struct xhci_hcd *xhci)
 	 * changing the programming leads to extra accesses even if the
 	 * controller is supposed to be halted. The controller ends up with
 	 * a fatal fault, and is then ripe for being properly reset.
-	 *
-	 * Special care is taken to only apply this if the device is behind
-	 * an iommu. Doing anything when there is no iommu is definitely
-	 * unsafe...
 	 */
-	if (!(xhci->quirks & XHCI_ZERO_64B_REGS) || !device_iommu_mapped(dev))
+	if (!(xhci->quirks & XHCI_ZERO_64B_REGS))
 		return;

 	xhci_info(xhci, "Zeroing 64bit base registers, expecting fault\n");
-- 
2.25.1