Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 4 Aug 2023 10:33:28 +0800
From:   Wu Zongyo <wuzongyo@mail.ustc.edu.cn>
To:     Sean Christopherson <seanjc@google.com>
Cc:     Tom Lendacky <thomas.lendacky@amd.com>,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org,
        linux-coco@lists.linux.dev
Subject: Re: [Question] int3 instruction generates a #UD in SEV VM
Message-ID: <ZMxjeB9PmCpJNgXF@iZuf6hx7901barev1c282cZ>
Reply-To: Wu Zongyo <wuzongyo@mail.ustc.edu.cn>
References: <4ebb3e20-a043-8ad3-ef6c-f64c2443412c@amd.com>
 <544b7f95-4b34-654d-a57b-3791a6f4fd5f@mail.ustc.edu.cn>
 <ZMpEUVsv5hSmrcH8@iZuf6hx7901barev1c282cZ>
 <ZMphvF+0H9wHQr5B@google.com>
 <bbc52f40-2661-3fa2-8e09-bec772728812@amd.com>
 <7a4f3f59-1482-49c4-92b2-aa621e9b06b3@amd.com>
 <bdf548d1-84cb-6885-c4eb-cbb16c4a3e3b@amd.com>
 <ZMsekJG8PF0f4sCp@iZuf6hx7901barev1c282cZ>
 <ZMto2Yza4rd2JdXf@iZuf6hx7901barev1c282cZ>
 <ZMu7Cl6im9JwjHIQ@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZMu7Cl6im9JwjHIQ@google.com>
Precedence: bulk

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.