Page MenuHomeFreeBSD

vtd: Increase DRHD_MAX_UNITS
ClosedPublic

Authored by erj on Jan 30 2023, 9:40 PM.
Tags
None
Referenced Files
F107115394: D38285.diff
Fri, Jan 10, 8:39 AM
Unknown Object (File)
Wed, Dec 25, 10:42 PM
Unknown Object (File)
Dec 5 2024, 1:17 AM
Unknown Object (File)
Oct 10 2024, 1:57 PM
Unknown Object (File)
Oct 7 2024, 1:33 PM
Unknown Object (File)
Oct 7 2024, 11:42 AM
Unknown Object (File)
Oct 5 2024, 12:00 AM
Unknown Object (File)
Oct 4 2024, 9:39 PM

Details

Summary

Observed on a couple Ice Lake-SP platforms (Intel Coyote Pass, Dell
R750), there are more than 8 DRHD sections enumerated in the DMAR ACPI
section. Since the previous limit was 8, this resulted in some of these
not being parsed by vtd when the iommu is initialized; in this case when
PCI devices are being passthru'd to a bhyve VM.

This omission later causes a kernel panic later in initialization when
devices could not be found in a valid DRHD scope because the DHRD
containing the device's scope was not added to vtd.

Signed-off-by: Eric Joyner <erj@FreeBSD.org>

PR: 268486
Sponsored by: Intel Corporation


I could not find anything on what a max limit on the number of DRHDs could be in the VT-d spec 4.0; should the drhds and vtdmaps arrays be turned into arbitrary-length linked lists instead?

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 49344
Build 46234: arc lint + arc unit

Event Timeline

erj requested review of this revision.Jan 30 2023, 9:40 PM
erj added a reviewer: Intel Networking.
erj edited the summary of this revision. (Show Details)
rew added a subscriber: rew.

I don't see any issues with this offhand - be nice to have this fixed for 13.2

This revision is now accepted and ready to land.Jan 30 2023, 10:23 PM
This revision was automatically updated to reflect the committed changes.

It would be nice to make these dynamically sized rather than a fixed-sized array. However, reviewing and integrating @kib's patch to use the ACPI_DMAR driver for this instead is probably the better long-term fix.

In D38285#871102, @jhb wrote:

It would be nice to make these dynamically sized rather than a fixed-sized array. However, reviewing and integrating @kib's patch to use the ACPI_DMAR driver for this instead is probably the better long-term fix.

Is D25672 what you're referring to/related to it?

In D38285#871126, @erj wrote:
In D38285#871102, @jhb wrote:

It would be nice to make these dynamically sized rather than a fixed-sized array. However, reviewing and integrating @kib's patch to use the ACPI_DMAR driver for this instead is probably the better long-term fix.

Is D25672 what you're referring to/related to it?

Yes, it is. It is old and require a work just to revive it. To get it into a committable state, much more work is needed. Also we do not have ACPI driver for AMD IOMMU.