Re: [Xen-devel] [PATCH 1/1 V5] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr

["Egger, Christoph" <chegger@xxxxxxxxx>]

On 12.08.13 16:04, Suravee Suthikulpanit wrote:
> On 8/12/2013 8:18 AM, Jan Beulich wrote:
>>>>> On 12.08.13 at 13:13, "Egger, Christoph" <chegger@xxxxxxxxx> wrote:
>>> On 12.08.13 11:01, Jan Beulich wrote:
>>>>>>> On 12.08.13 at 10:57, "Egger, Christoph" <chegger@xxxxxxxxx> wrote:
>>>>> On 08.08.13 08:47, Jan Beulich wrote:
>>>>>> In any case - explaining how nestedhvm_enabled() could end up
>>>>>> returning a value different from hvm_svm_enabled() would help
>>>>>> my understanding.
>>>>> nestedhvm_enabled() returns true when 'nestedhvm=1' in the
>>>>> guest config file.
>>>>>
>>>>> hvm_svm_enabled() returns true when the hvm guest enabled SVM
>>>>> in EFER.
>>>> And the guest should certainly be disallowed to enable SVM in
>>>> EFER when nestedhvm was not 1 in the config file.
>>> That's correct. The guest should also never see SVM available via
>>> cpuid.
>>> Analogous same regarding VMX on Intel.
>> So Suravee, bottom line from this is: Replace the prior checks
>> instead of adding the new ones.
>>
>> Jan
>>
>>
> Ok... I will replace the hvm_svm_enabled() to check the EFER.SVME bit
> instead. 
> I sent out the V6 on Friday which I have separated the patch into two. 
> Would you mind taking one last quick look.

Looking into the how hvm_svm_enabled() is implemented ...

/* True when l1 guest enabled SVM in EFER */
#define hvm_svm_enabled(v) \
    (!!((v)->arch.hvm_vcpu.guest_efer & EFER_SVME))

... it is already doing this.

Christoph


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