[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Best regards,
Yang



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.