Re: [Xen-devel] [PATCH] Nested VMX: prohabit virtual vmentry/vmexit during IO emulaiton

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

On Mon, Jan 20, 2014 at 12:10 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 18.01.14 at 15:32, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-01-17:
>>>>>> On 17.01.14 at 07:39, Yang Zhang <yang.z.zhang@xxxxxxxxx> wrote:
>>>> Sometimes, L0 need to decode the L2's instruction to handle IO
>>>> access directly.
>>>> And L0 may get X86EMUL_RETRY when handling this IO request. At same
>>>> time, if there is a virtual vmexit pending (for example, an
>>>> interrupt pending to inject to L1) and hypervisor will switch the
>>>> VCPU context from L2 to L1. Now we already in L1's context, but
>>>> since we got a X86EMUL_RETRY just now and this means hyprevisor will
>>>> retry to handle the IO request later and unfortunately, the retry
>>>> will happen in L1's context. And it will cause the problem.
>>>> The fixing is that if there is a pending IO request, no virtual
>>>> vmexit/vmentry is allowed.
>>>>
>>>> Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
>>>> ---
>>>>  xen/arch/x86/hvm/vmx/vvmx.c |    8 ++++++++
>>>
>>> Didn't we agree earlier on to do this in common code?
>>>
>>
>> I think you agree with this fixing. Let me have a double check: Do you mean
>> move the check to nhvm_interrupt_block () as Christoph suggested or move to
>> another place in common code? Christoph' s suggestion doesn't solve the issue
>> as I said in previous thread. Also, since SVM and VMX handle the vmswitch
>> totally independent, there is no proper point to put the check in common code
>> to cover both.
>
> Okay, fine with me then as is. Awaiting a VMX maintainer ack then...

Acked-by: Jun Nakajima <jun.nakajima@xxxxxxxxx>

>
> Jan
>


-- 
Jun
Intel Open Source Technology Center

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