|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |