On Thu, Jan 25, 2024 at 10:49:56AM +0000, Nilesh Javali wrote: > > We have extensively verified this patch set with IOMMU enabled and see > no regression when VT and SRIOV are enabled. However issues are observed > only when VT, VT-D and SRIOV are enabled in the HW BIOS. I don't understand what having IOMMU enabled while VT-d is disabled in the BIOS settings actually means. Isn't VT-d Intel's name for it's IOMMU implemenation? Does disabling VT-d support but setting intel_iommu=on actually do anything? > In the failure case, with VT-D enabled, we observe the OS fails to boot with > DMAR timeout error. > > " **] A start job is running for Network Manager (2min 6s / no limit) > [ 147.069016] DMAR: VT-d detected Invalidation Time-out Error: SID 0 > [ 147.069016] DMAR: DRHD: handling fault status reg 40 > [ 147.080924] DMAR: QI HEAD: Device-TLB Invalidation qw0 = 0xaf0300100003, qw1 = 0x7ffffffffffff001 > [ 147.090207] DMAR: QI PRIOR: Invalidation Wait qw0 = 0x200000025, qw1 = 0x10005f634". > > With your proposed changes, please confirm if you see no issues with > VT-D enabled on Intel/AMD platform. I've just gone back and tested on a R320 with a Xeon E5-2420, this systems BIOS does not have seperate VT and VT-d setting, but VT-d does appear to be on when the single virtualization features setting is enabled. - A kernel with my v1 patches logs into a target just fine. - These v3 patches fail. My configuration is probably different, I don't see a network manager online stall but I do see segfaults in iscsiuio. - Adding back the dma_device lines to the v3 patches, keeping the union cleanups you did in place, and it goes back to working. > Also based on our observation the issue with VT-D enabled is not > related to the current patch set under test. Yes, Jerry Snitsel noted that the IOMMU code had been clearing the __GFP_COMP flag for longer than the DMA API has been rejecting it. So IOMMU support has had issues for longer, but I think we can fix both by doing this correctly. Thanks, Chris Leech
