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

Re: [Xen-devel] [PATCH 11/27] x86/hvm: Improve hvm_efer_valid() using named features



On 05/01/17 11:34, Jan Beulich wrote:
>>>> On 04.01.17 at 13:39, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -914,56 +914,35 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
>> hvm_domain_context_t *h)
>>  }
>>  
>>  /* Return a string indicating the error, or NULL for valid. */
>> -const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
>> -                           signed int cr0_pg)
>> +const char *hvm_efer_valid(const struct vcpu *v, uint64_t value, int cr0_pg)
> Please can we keep the "signed" here, to make clear signedness
> indeed matters (as opposed to various other uses of plain int we
> still have which could equally well be unsigned int)?

Ok.

>
> Other than that
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> albeit I have one more question:
>
>>      if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
>>          return "LMSLE without support";
> Do you have any plans to include such non-CPUID-based features
> into the policy?

That is on my TODO list, because one way or another, I will need it when
doing the migration improvements.

One way or another I think we are going to have to non-architectural
information in our architectural representation of the policy.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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