[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-4.16] x86/cpuid: prevent shrinking migrated policies max leaves



On 11/11/2021 14:04, Roger Pau Monné wrote:
> On Thu, Nov 11, 2021 at 10:26:29AM +0100, Jan Beulich wrote:
>> On 10.11.2021 19:17, Andrew Cooper wrote:
>>> On 10/11/2021 17:40, Roger Pau Monne wrote:
>>>> diff --git a/tools/libs/guest/xg_cpuid_x86.c 
>>>> b/tools/libs/guest/xg_cpuid_x86.c
>>>> index 198892ebdf..3ffd5f683b 100644
>>>> --- a/tools/libs/guest/xg_cpuid_x86.c
>>>> +++ b/tools/libs/guest/xg_cpuid_x86.c
>>>> @@ -638,6 +638,13 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t 
>>>> domid, bool restore,
>>>>          }
>>>>      }
>>>>  
>>>> +    /*
>>>> +     * Do not try to shrink the policy if restoring, as that could cause
>>>> +     * guest visible changes in the maximum leaf fields.
>>>> +     */
>>>> +    if ( !restore )
>>>> +        x86_cpuid_policy_shrink_max_leaves(p);
>>> Nothing in xc_cpuid_apply_policy() changes any of the max leaves, so
>>> this is dead logic.
>> I guess you mean nothing there does anything which would result in
>> shrinking of the max leaves by calling this function? Yet even if
>> so, isn't the call here to take care of any earlier changes which
>> might have resulted in fully blank tail leaves?
> AFAICT the featureset (optionally) passed in as a parameter could
> result in certain leaves being zeroed and thus allow for the max leaf
> to shrink.
>
> So while xc_cpuid_apply_policy doesn't change the max leaves fields,
> it can potentially zero certain leaves allowing to shrink the reported
> max leaf.

Hmm true, although I don't anticipate this having an effect in practice.

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.