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@xxxxxxxxxx
