[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely
On Thu, Mar 21, 2019 at 08:26:20PM +0000, Andrew Cooper wrote: > It turns out that this code was previously dead. > > c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling > acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised > enough for acpi_parse_one_drhd() to not take the > > /* Skip checking if segment is not accessible yet. */ > > path unconditionally. However, some systems have DMAR tables which list > devices which are disabled by user choice (in particular, Dell PowerEdge R740 > with I/O AT DMA disabled), and turning off all IOMMU functionality in this > case is entirely unhelpful behaviour. > > Leave the warning which identifies the problematic devices, but drop the > remaining logic. This leaves the system in better overall state, and working > in the same way that it did in previous releases. > > Reported-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> > Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> I think this is a more sane behavior. > - if ( invalid_cnt ) > - { > - if ( iommu_workaround_bios_bug && > - invalid_cnt == dmaru->scope.devices_cnt ) > - { > - printk(XENLOG_WARNING VTDPREFIX > - " Workaround BIOS bug: ignoring DRHD (no devices in > its scope are PCI discoverable)\n"); > - > - scope_devices_free(&dmaru->scope); > - iommu_free(dmaru); > - xfree(dmaru); > - } > - else > - { > - printk(XENLOG_WARNING VTDPREFIX > - " DRHD is invalid (some devices in its scope are not > PCI discoverable)\n"); > - printk(XENLOG_WARNING VTDPREFIX > - " Try \"iommu=force\" or > \"iommu=workaround_bios_bug\" if you really want VT-d\n"); > - ret = -EINVAL; > - } The workaround_bios_bug option seems quite pointless anyway, it only prevents propagating the error to the caller if all the devices in the DMAR scope are non-existent, or else the DMAR won't be registered and an error would be returned to the caller. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |