[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu
On Mon, Mar 14, 2022 at 3:22 AM Tian, Kevin <kevin.tian@xxxxxxxxx> wrote: > > > From: Lengyel, Tamas <tamas.lengyel@xxxxxxxxx> > > Sent: Friday, March 11, 2022 2:45 AM > > > > During VM fork resetting a failed vmentry has been observed when the reset > > is performed immediately after a STI instruction executed. This is due to > > the guest interruptibility state in the VMCS being modified by STI but the > > subsequent reset removes the IF bit from FLAGS, causing the failed vmentry. > > I didn't get the rationale here. Before this patch the interruptibility state > is > not saved/restored thus I suppose after reset it will be cleared thus aligned > with RFLAGS.IF=0. Can you elaborate a bit how exactly above problem is > caused? The problem is that the interruptibility state is not cleared and thus isn't aligned with RFLAGS.IF=0 after RFLAGS is reset. They go out of sync leading to the failed vmentry. The interruptibility state needs to be included in the hvm hw cpu struct for it to get re-aligned during reset to avoid the failed vmentry. > > > > > Include the interruptibility state information in the public hvm_hw_cpu > > struct > > so that the CPU can be safely saved/restored. > > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx> > > --- > > xen/arch/x86/hvm/hvm.c | 9 +++++---- > > xen/arch/x86/hvm/vmx/vmx.c | 4 ++++ > > xen/arch/x86/include/asm/hvm/hvm.h | 26 > > Why is this change only applied to vmx instead of svm? VM forking is implemented only for vmx, thus this change is only relevant where a VM would be immediately reset after a STI instruction. Normal VM save/restore/migration doesn't attempt to capture a VM state immediately after STI thus it's not relevant for SVM. Tamas
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |