[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <544b7f95-4b34-654d-a57b-3791a6f4fd5f@mail.ustc.edu.cn>
Date: Mon, 31 Jul 2023 23:45:29 +0800
From: wuzongyong <wuzongyo@...l.ustc.edu.cn>
To: Tom Lendacky <thomas.lendacky@....com>,
Sean Christopherson <seanjc@...gle.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org,
linux-coco@...ts.linux.dev
Subject: Re: [Question] int3 instruction generates a #UD in SEV VM
On 2023/7/31 23:03, Tom Lendacky wrote:
> 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[*]?
Firstly, I'm sorry for sending muliple mails with the same content. I thought the mails I sent previously
didn't be sent successfully.
And let's talk the problem here.
>>
>> : > > 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?
>> :
Yes, every time.
The processor I used is EPYC 7T83.
>> : 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?
Ok, I will try to do that.
>
> Thanks,
> Tom
>
>>
>> [*] https://lore.kernel.org/all/ZMFd5kkehlkIfnBA@google.com
Powered by blists - more mailing lists