Created attachment 293699 [details] dmesg When enabling tboot, some IO devices might encounter the DMA failure shown as follows (during booting): ------------------------------------------------------------------- usb 1-1: new high-speed USB device number 2 using ehci-pci ehci-pci 0000:00:1a.0: swiotlb buffer is full (sz: 8 bytes), total 0 (slots), used 0 (slots) usb 1-1: device descriptor read/64, error -11 ------------------------------------------------------------------- The USB device connected to this USB host controller cannot be used due to the above-mentioned failure message. The issue happens with the following conditions: 1. DMA address > 4G memory address. 2. Default domain type: identity domain 3. Enable tboot: the statement 'swiotlb = 0' is evaluated in tboot_force_iommu(). Please find the attached dmesg log.
Created attachment 293701 [details] Proposed fix patch Hi Baolu, Please find the attachment for the proposed fix patch. I would like to sync up with you before submitting this patch. Here is the additional info: Bisect points at commit 327d5b2fee91 ("iommu/vt-d: Allow 32bit devices to uses DMA domain") as the offending one. This commit removes the chance to convert the identity domain to the DMA domain if the address capability of the IO device is less than the size of the system memory. The commit log lists many problems about the domain conversion. Do you have any concern about this patch since it returns IOMMU_DOMAIN_DMA domain type in device_def_domain_type()? It looks like this is the only solution for the issue. However, I might miss something. Any thoughts? Thanks in advance.
Setting swiotlb to 0 if tboot is enable is really bad. Even the IOMMU is on, some devices might work in identity mode hence swiotlb is needed. #ifdef CONFIG_SWIOTLB swiotlb = 0; #endif Can below changes fix this problem? diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index 992fb1415c0f..96b117d2f32b 100644 --- a/arch/x86/kernel/tboot.c +++ b/arch/x86/kernel/tboot.c @@ -517,13 +517,10 @@ int tboot_force_iommu(void) if (intel_iommu_tboot_noforce) return 1; - if (no_iommu || swiotlb || dmar_disabled) + if (no_iommu || dmar_disabled) pr_warn("Forcing Intel-IOMMU to enabled\n"); dmar_disabled = 0; -#ifdef CONFIG_SWIOTLB - swiotlb = 0; -#endif no_iommu = 0; return 1;
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c > index 992fb1415c0f..96b117d2f32b 100644 > --- a/arch/x86/kernel/tboot.c > +++ b/arch/x86/kernel/tboot.c > @@ -517,13 +517,10 @@ int tboot_force_iommu(void) > if (intel_iommu_tboot_noforce) > return 1; > > - if (no_iommu || swiotlb || dmar_disabled) > + if (no_iommu || dmar_disabled) > pr_warn("Forcing Intel-IOMMU to enabled\n"); > > dmar_disabled = 0; > -#ifdef CONFIG_SWIOTLB > - swiotlb = 0; > -#endif > no_iommu = 0; > > return 1; Nice catch. Originally, I though someone intentionally sets 'swiotlb = 0' because IOMMU is forcibly enabled along with enabling tboot. This means that the bounce buffer is not needed because of enabling IOMMU. So, I proposed another solution by keeping this logic ('swiotlb = 0'). However, I think your solution is better since IOMMU domain might be identity mapping. Thanks. Unfortunately, our lab network cannot be accessed from this Wednesday. I'll verify your solution and let you know the result next week. Please stay tuned.
Hi Baolu, Confirmed that your patch could the issue (tested on 5.10-rc5). Feel free to add my tag when you submit the patch. Reported-and-tested-by: Adrian Huang <ahuang12@lenovo.com>