[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 11/17] x86/CPUID: adjust extended leaves out of range clearing
On 15.04.2021 14:48, Andrew Cooper wrote: > On 23/11/2020 14:32, Jan Beulich wrote: >> --- a/xen/lib/x86/cpuid.c >> +++ b/xen/lib/x86/cpuid.c >> @@ -232,7 +232,9 @@ void x86_cpuid_policy_clear_out_of_range >> ARRAY_SIZE(p->xstate.raw) - 1); >> } >> >> - zero_leaves(p->extd.raw, (p->extd.max_leaf & 0xffff) + 1, >> + zero_leaves(p->extd.raw, >> + ((p->extd.max_leaf >> 16) == 0x8000 >> + ? (p->extd.max_leaf & 0xffff) + 1 : 0), >> ARRAY_SIZE(p->extd.raw) - 1); > > Honestly, this is unnecessary complexity and overhead, and the logic is > already hard enough to follow. > > There won't be extd.max_leaf with the high half != 0x8000 in real > policies, because of how we fill them. Nor ought there to be, given the > intended meaning of this part of the union. > > I think we simply forbid this case, rather than taking extra complexity > to cope with it. Approximately all VMs will have 0x80000008 as a > minimum, and I don't think catering to pre-64bit Intel CPUs is worth our > effort either. "Forbid" has got to mean something other than "assume all input is fine". Aiui guest config files can restrict the maximum sub-leaves exposed to a guest. If we don't want to handle the case here, where else to you suggest we at least and complain about the broken assumption? (IOW I'd be okay dropping this patch if your "forbid" actually means some enforcement elsewhere, and then perhaps a comment pointing there ahead of the zero_leaves() invocation here.) Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |