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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.13 at 16:40, "Egger, Christoph" <chegger@xxxxxxxxx> wrote:
> 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.

Right - my request also was to replace the nestedhvm_enabled()
checks in question with hvm_svm_enabled() ones, rather than
checking both.

Jan


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