On Tue, Mar 21, 2023 at 07:00:58AM +0100, Juergen Gross wrote:
I guess you are asking because the next test seems to catch the same case?
I think it doesn't, e.g. for the case of unknown hypervisors (which shows that
X86_HYPER_NATIVE in theory should be named X86_HYPER_NATIVE_OR_UNKNOWN, or it
should be split into X86_HYPER_NATIVE and X86_HYPER_UNKNOWN).
Yeah, we don't care about unknown hypervisors. They'll crash'n'burn
anyway.
My intent is to have every case properly documented with a comment above it
instead of one huge compound conditional.
It basically doesn't matter.
It doesn't matter now. Until someone decides to "redefine" how MTRRs
should be done again because the next representative from the virt zoo
decided to do magic pink ponies.
I'm not taking any chances anymore judging by the amount of crap that
gets sent into arch/x86/ to support some weird guest contraption.
The only possibility of mtrr_state.enabled to be set at this point is a
previous call of mtrr_overwrite_state().
Sure, pls make it explicit and defensive so that it is perfectly clear
what's going on.
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature