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

Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid



On 08/12/15 08:28, Jan Beulich wrote:
>>>> On 07.12.15 at 17:48, <roger.pau@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu 
>> *v, uint64_t value,
>>      {
>>          unsigned int level;
>>  
>> -        ASSERT(v == current);
>> +        ASSERT(v->domain == current->domain);
>>          hvm_cpuid(0x80000000, &level, NULL, NULL, NULL);
>>          if ( level >= 0x80000001 )
>>          {
>> @@ -1912,7 +1912,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const 
>> struct vcpu *v,
>>      {
>>          unsigned int level;
>>  
>> -        ASSERT(v == current);
>> +        ASSERT(v->domain == current->domain);
>>          hvm_cpuid(0, &level, NULL, NULL, NULL);
>>          if ( level >= 1 )
>>              hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
> The only reason both functions get v passed are the two ASSERT()s.
> Relaxing them means you should now be passing a const struct
> domain * instead.

v is correct here.  cpuid information is genuinely per-vcpu, although
this isn't currently reflected in Xen's understanding of the matter.

Part of my further cpuid improvements will be to fix Xen's
understanding. i.e. domain_cpuid() will soon start taking a vcpu parameter.

~Andrew

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


 


Rackspace

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