* RE: [EXTERNAL] Re: Alternate Injection related questions
2025-05-27 17:52 ` Alternate Injection related questions Melody (Huibo) Wang
@ 2025-05-27 18:23 ` Jon Lange
0 siblings, 0 replies; 2+ messages in thread
From: Jon Lange @ 2025-05-27 18:23 UTC (permalink / raw)
To: Melody (Huibo) Wang, Lendacky, Thomas, Jörg Rödel,
coconut-svsm@lists.linux.dev
The SVSM will check the "no further signal" flag the next time it enables interrupts. If that flag is set, the SVSM will act as if it has just received #HV and the pending interrupts will be delivered.
The design here is that "no further signal" indicates whether there is an event that has not been processed. This is the only information that the SVSM can use to determine whether there are pending events to dispatch. The #HV exception forces it to examine that flag, but the SVSM can choose to check the flag at any time.
For example, look at raw_irqs_enable, and you'll see this code:
// Now that interrupts are enabled, process any #HV events that may be
// pending.
this_cpu().process_hv_events_if_required();
There is similar logic in the IRET path to check whether interrupts were enabled at the time the exception was taken so that the #HV doorbell page can be examined. Look for the "default_return" label.
-Jon
-----Original Message-----
From: Melody (Huibo) Wang <huibo.wang@amd.com>
Sent: Tuesday, May 27, 2025 10:52 AM
To: Jon Lange <jlange@microsoft.com>; Lendacky, Thomas <Thomas.Lendacky@amd.com>; Jörg Rödel <joro@8bytes.org>; coconut-svsm@lists.linux.dev
Subject: [EXTERNAL] Re: Alternate Injection related questions
Sorry for re-sending this since I had the wrong mailing list in the previous one.
On 5/27/2025 10:39 AM, Melody (Huibo) Wang wrote:
> Hi Folks,
>
> I have a few questions, can you please help?
>
> I found that when an #HV arrives when interrupts are disabled in the SVSM, the #HV handler will postpone the #HV, but the postponing simply returns.
>
> Who should re-inject this #HV again?
>
> postpone_hv:
> // HV gets postponed
> popq %rcx
> popq %rbx
> popq %rax
> addq $8, %rsp
> iretq
>
> Is the hypervisor supposed to re-inject the #HV hoping that interrupts will be enabled?
>
> How is the hypervisor supposed to know whether a #HV which was postponed, was actually handled so that it doesn't inject it again?
>
> In SVSM code now, the SVSM will read the doorbell page for extended interrupt information without checking even there is a #HV coming in. Why are we doing this? I think this needs to be triggered by a #HV handler instead of reading the doorbell page automatically. Right?
>
> I have one more question about gdb tool, "https://coconut-svsm.github.io/svsm/installation/INSTALL/#debugging-using-gdb". I tried to use the tool, but it does not work, I have enabled it :
>
> "kernel": {
> "svsm": {
> "features": "enable-gdb",
> But not able to make it work. This is the log:
>
> $ sudo gdb --ex "target extended-remote /dev/pts/4"
> GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> Copyright (C) 2024 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu/.
> org%2Flicenses%2Fgpl.html&data=05%7C02%7Cjlange%40microsoft.com%7C1969
> d34327a3448c091408dd9d473987%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C638839651456899199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=riKaPvm%2BpR6V2BB33Irz6Ds9qRNDhUJfVa40QsaLaqY%3D&re
> served=0> This is free software: you are free to change and
> redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> Remote debugging using /dev/pts/4
> Ignoring packet error, continuing...
> warning: unrecognized item "timeout" in "qSupported" response Ignoring
> packet error, continuing...
> Ignoring packet error, continuing...
> Remote replied unexpectedly to 'vMustReplyEmpty': timeout
> (gdb) quit
>
>
> Thanks,
> Melody
>
^ permalink raw reply [flat|nested] 2+ messages in thread