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:   Mon, 31 Jul 2023 07:30:00 -0700
In-Reply-To: <8eb933fd-2cf3-d7a9-32fe-2a1d82eac42a@mail.ustc.edu.cn>
Mime-Version: 1.0
References: <8eb933fd-2cf3-d7a9-32fe-2a1d82eac42a@mail.ustc.edu.cn>
Message-ID: <ZMfFaF2M6Vrh/QdW@google.com>
Subject: Re: [Question] int3 instruction generates a #UD in SEV VM
From:   Sean Christopherson <seanjc@google.com>
To:     wuzongyong <wuzongyo@mail.ustc.edu.cn>
Cc:     linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
        kvm@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Sat, Jul 29, 2023, wuzongyong wrote:
> Hi,
> I am writing a firmware in Rust to support SEV based on project td-shim[1].
> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
> #UD.

...

> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
> #BP.
> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
> Any suggestion is appreciated!

Have you tried my suggestions from the other thread[*]?

  : > > I'm curious how this happend. I cannot find any condition that would
  : > > cause the int3 instruction generate a #UD according to the AMD's spec.
  : 
  : One possibility is that the value from memory that gets executed diverges from the
  : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
  : be the case in this test), stale cache/tlb entries, etc.
  : 
  : > > BTW, it worked nomarlly with qemu and ovmf.
  : > 
  : > Does this happen every time you boot the guest with your firmware? What
  : > processor are you running on?
  : 
  : And have you ruled out KVM as the culprit?  I.e. verified that KVM is NOT injecting
  : a #UD.  That obviously shouldn't happen, but it should be easy to check via KVM
  : tracepoints.

[*] https://lore.kernel.org/all/ZMFd5kkehlkIfnBA@google.com