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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.12.15 at 12:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

You can't have both: Either the ASSERT() remains as it was, or
you stand on the position voiced along with your R-b that only
the domain matters here (in which case passing around v just to
obtain v->domain is bogus).

Jan


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