On Thu, Aug 03, 2023 at 02:34:50PM +0000, Sean Christopherson wrote:
> On Thu, Aug 03, 2023, Wu Zongyo wrote:
> > On Thu, Aug 03, 2023 at 11:27:12AM +0800, Wu Zongyo wrote:
> > > > > >
> > > > > > I'm guessing it was a #NPF, too. Could it be related to the changes that
> > > > > > went in around svm_update_soft_interrupt_rip()?
> > > Yes, it's a #NPF with exit code 0x400.
> > >
> > > There must be something I didn't handle corretly since it behave normally with
> > > qemu & ovmf If I don't add int3 before mcheck_cpu_init().
> > >
> > > So it'a about memory, is there something I need to pay special attention
> > > to?
> > >
> > > Thanks
> > I check the fault address of #NPF, and it is the IDT entry address of
> > the guest kernel. The NPT page table is not constructed for the IDT
> > entry and the #NPF is generated when guest try to access IDT.
> >
> > With qemu & ovmf, I didn't see the #NPF when guest invoke the int3
> > handler. That means the NPT page table has already been constructed, but
> > when?
>
> More than likely, the page was used by the guest at some point earlier in boot.
> Why the page is faulted in for certain setups but not others isn't really all
> that interesting in terms of fixing the KVM bug, both guest behaviors are completely
> normal and should work.
>
> Can you try this patch I suggested earlier? If this fixes the problem, I'll post
> a formal patch.
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index d381ad424554..2eace114a934 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -385,6 +385,9 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu,
> }
>
> if (!svm->next_rip) {
> + if (sev_guest(vcpu->kvm))
> + return 0;
> +
> if (unlikely(!commit_side_effects))
> old_rflags = svm->vmcb->save.rflags;
>
Yes, the patch solves the problem.
