Messages in this thread | | | Date | Tue, 21 Mar 2023 16:49:36 +0100 | Subject | Re: [PATCH v4 03/12] x86/mtrr: support setting MTRR state for software defined MTRRs | From | Juergen Gross <> |
| |
On 21.03.23 11:30, Borislav Petkov wrote: > 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.
Okay, I'll drop that test.
> 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.
Okay, will do the modification you were suggesting.
Juergen [unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |