On 06/22/2018 06:28 PM, Jan Beulich wrote:
>>>> On 13.06.18 at 10:52, <rcojoc...@bitdefender.com> wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> }
>> }
>>
>> - if ( idx != vcpu_altp2m(v).p2midx )
>> + if ( idx != INVALID_ALTP2M && idx != vcpu_altp2m(v).p2midx )
>> {
>> BUG_ON(idx >= MAX_ALTP2M);
>
> In the code immediately ahead of this there is an INVALID_ALTP2M check
> already (in the else branch). If the __vmread() can legitimately produce
> this value, why would the domain be crashed when getting back
> INVALID_ALTP2M in the other case? I think the correctness of your change
> can only be judged once both code paths behave consistently.
You're right, I had somehow convinced myself that this is a #VE-specific
problem, but it looks like a generic altp2m problem. I'll simulate the
other branch in the code and see what it does with my small test
application.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
