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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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