Re: [Xen-devel] [PATCH 1/2] x86/xstate: Use the CPUID policy in valid_xcr0(), rather than allowing all features

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/07/18 15:48, Jan Beulich wrote:
>>>> On 18.07.18 at 14:30, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Backporting notes: This is safe in the restore case, but only back as far as
>> the introduction of cpuid_policy infrastructure.  Before then, a restore
>> boolean needs to be pumbed down as well, and used to select between the
>> hardware maximum value and calls to {hvm,pv}_cpuid() to find the
>> toolstack-chosen level.
> So can I take this to mean that for ...
>
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1170,7 +1170,7 @@ long arch_do_domctl(
>>              if ( _xcr0_accum )
>>              {
>>                  if ( evc->size >= PV_XSAVE_HDR_SIZE + XSTATE_AREA_MIN_SIZE )
>> -                    ret = validate_xstate(_xcr0, _xcr0_accum,
>> +                    ret = validate_xstate(d, _xcr0, _xcr0_accum,
> ... this and ...
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1254,7 +1254,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
>> hvm_domain_context_t *h)
>>      ctxt = (struct hvm_hw_cpu_xsave *)&h->data[h->cur];
>>      h->cur += desc->length;
>>  
>> -    err = validate_xstate(ctxt->xcr0, ctxt->xcr0_accum,
>> +    err = validate_xstate(d, ctxt->xcr0, ctxt->xcr0_accum,
> ... this there's no ordering issue on master (i.e. policy arrives before
> register state)?

You are correct.  In the case that the policy hasn't arrived on migrate,
d->arch.cpuid is the applicable max policy.

The reason we still need the restore boolean for CR4 is that we have to
account for HVM_PARAM_NESTEDHVM having not having arrived in the
migration stream yet.  (If it weren't for this HVM_PARAM, I'd have
dropped that bodge with the introduction of the cpuid_policy
infrastructure).

The CR4 problem can't be fixed until the {get,set}_cpu_policy
infrastructure is in place, and we rearrange the toolstack to
restore/fabricate the domain policy before restoring register/memory
state, at which point cp->basic.vmx will be the single, authoritative
signal of whether CR4.VMXE is valid.  (Fixing this is definitely still
on the todo list).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel