Page MenuHomeFreeBSD

x86: Add COMPAT_LINUX_MPTABLE_BUGS option
ClosedPublic

Authored by cperciva on Jul 13 2022, 12:47 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 4 2024, 5:52 AM
Unknown Object (File)
Mar 4 2024, 5:52 AM
Unknown Object (File)
Mar 4 2024, 5:52 AM
Unknown Object (File)
Mar 4 2024, 5:52 AM
Unknown Object (File)
Mar 3 2024, 3:34 AM
Unknown Object (File)
Feb 6 2024, 7:35 PM
Unknown Object (File)
Jan 15 2024, 2:49 AM
Unknown Object (File)
Dec 30 2023, 5:24 AM
Subscribers

Details

Summary

Linux has two bugs in its handling of the x86 MP table:

  1. It assumes that there is always 640 kB of base memory, and looks for

the MP table in the top kB of this even if the memory map indicates
that memory location does not exist.

  1. It ignores that entry_count field and instead iterates through the

MP table by scanning until it runs out of bytes in the table.

The Firecracker VM (and probably other related VMs) relies on both of
these bugs. With the COMPAT_LINUX_MPTABLE_BUGS option, we search for
the MP table at address 639k even if that isn't in the memory map; and
replace a zeroed entry_count with a value computed from scanning the
table until we run out of table bytes.

Sponsored by: https://www.patreon.com/cperciva

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 46399
Build 43288: arc lint + arc unit

Event Timeline

This is a really odd use of the COMPAT_xxx namespace.
Is there another way to express this w/o it being there?
Otherwise, it's fine.

This revision is now accepted and ready to land.Jul 13 2022, 12:57 AM
In D35799#812385, @imp wrote:

This is a really odd use of the COMPAT_xxx namespace.

I'll admit that it's a bit opinionated -- to be honest, that's deliberate. I find it
useful to have names which make clear that we're working around bugs, since
that prompts people to check later if the workarounds can be removed (rather
than just saying "gee there must be some reason Colin added this").

Is there another way to express this w/o it being there?
Otherwise, it's fine.

I considered making it a tunable but for Firecracker we have to compile
tunables into the kernel anyway (since there is no boot loader) so I figured it
was simpler to make it a kernel option -- and that way the GENERIC kernel
build doesn't need to include the code at all.

We mostly use COMPAT_xxx for being able to run old binaries, or 32-bit binaries or linux binaries...
Not for being compatible with a funked up situation.

I'd make it default with a tunable to turn it off since Linux has been doing it for all these years...
Years ago, I would be very afraid of this. These days I'm less so because Linux not booting on enough systems would cause this behavior to be fixed...

LINUX_COMPAT_MPTABLE_PARSING is the only suggestion I have and that might be too ugly :)

I think Linux prefers ACPI when it's available. For that matter, FreeBSD doesn't include mptable in GENERIC -- so neither Linux nor FreeBSD exercise their MP Table code very often. In light of that I figured it was safer to have this standards-non-compliant workaround turned off by default.

LINUX_COMPAT_MPTABLE_PARSING

Or MPTABLE_LINUX_BUG_COMPAT perhaps

Change option name per emaste's suggestion.

This revision now requires review to proceed.Jul 20 2022, 11:21 PM

LINUX_COMPAT_MPTABLE_PARSING

Or MPTABLE_LINUX_BUG_COMPAT perhaps

Thanks, I like that name. Among other thing it has the advantage of sorting with MPTABLE_FORCE_HTT.

@imp Are you ok with the name MPTABLE_LINUX_BUG_COMPAT?

@imp Are you ok with the name MPTABLE_LINUX_BUG_COMPAT?

Yes.

This revision is now accepted and ready to land.Aug 16 2022, 11:41 PM
This revision was automatically updated to reflect the committed changes.