| Message ID | 63da915f-03dc-f846-3c6b-e90890d1f8fc@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | VT-d: further small corrections | expand |
> From: Jan Beulich <jbeulich@suse.com> > Sent: Tuesday, November 23, 2021 9:40 PM > > As of commit 6773b1a7584a ("VT-d: Don't assume register-based > invalidation is always supported") we don't (try to) use register based > invalidation anymore when that's not supported by hardware. Hence > there's also no point in the respective check, avoiding pointless IOMMU > initialization failure. After all the spec (version 3.3 at the time of > writing) doesn't say what the respective Extended Capability Register > field would contain in such a case. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> > > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -1228,7 +1228,8 @@ int __init iommu_alloc(struct acpi_drhd_ > > if ( cap_fault_reg_offset(iommu->cap) + > cap_num_fault_regs(iommu->cap) * PRIMARY_FAULT_REG_LEN > > PAGE_SIZE || > - ecap_iotlb_offset(iommu->ecap) >= PAGE_SIZE ) > + (has_register_based_invalidation(iommu) && > + ecap_iotlb_offset(iommu->ecap) >= PAGE_SIZE) ) > { > printk(XENLOG_ERR VTDPREFIX "IOMMU: unsupported\n"); > print_iommu_regs(drhd);
--- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1228,7 +1228,8 @@ int __init iommu_alloc(struct acpi_drhd_ if ( cap_fault_reg_offset(iommu->cap) + cap_num_fault_regs(iommu->cap) * PRIMARY_FAULT_REG_LEN > PAGE_SIZE || - ecap_iotlb_offset(iommu->ecap) >= PAGE_SIZE ) + (has_register_based_invalidation(iommu) && + ecap_iotlb_offset(iommu->ecap) >= PAGE_SIZE) ) { printk(XENLOG_ERR VTDPREFIX "IOMMU: unsupported\n"); print_iommu_regs(drhd);
As of commit 6773b1a7584a ("VT-d: Don't assume register-based invalidation is always supported") we don't (try to) use register based invalidation anymore when that's not supported by hardware. Hence there's also no point in the respective check, avoiding pointless IOMMU initialization failure. After all the spec (version 3.3 at the time of writing) doesn't say what the respective Extended Capability Register field would contain in such a case. Signed-off-by: Jan Beulich <jbeulich@suse.com>