lkml.org 
[lkml]   [2023]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Question] int3 instruction generates a #UD in SEV VM
From
On 7/31/23 09:30, Sean Christopherson wrote:
> 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.

I have a feeling that KVM is injecting the #UD, but it will take
instrumenting KVM to see which path the #UD is being injected from.

Wu Zongyo, can you add some instrumentation to figure that out if the
trace points towards KVM injecting the #UD?

Thanks,
Tom

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

\
 
 \ /
  Last update: 2023-07-31 17:04    [W:0.107 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site