[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 |