<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<p style="font-family:Calibri;font-size:10pt;color:#0000FF;margin:5pt;font-style:normal;font-weight:normal;text-decoration:none;" align="Left">
[AMD Official Use Only - AMD Internal Distribution Only]<br>
</p>
<br>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks Jon for writing and sharing this! I have a few questions/comments on the spec:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">p.1: “</span></i><i><span style="font-size:11.0pt">SVSM involvement is required to present interrupts to the guest OS, so when a guest OS interrupt<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">becomes deliverable, it is necessary to cause the SVSM to run”<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I was a bit confused by this wording (and worry others may be too). With the Alternate Injection feature, the SVSM may “queue” interrupts for the guest OS, but the HW is actually what “delivers” the interrupt
(meaning vectoring to the handler through the IDT). Additionally, the term “becomes deliverable” here may not be clear. I believe your intention is that when the HV decides to deliver a guest OS interrupt, it must cause the SVSM to run. However when a previously
sent interrupt that was pending (say because RFLAGS.IF=0 in the guest) becomes deliverable because the guest did STI, that does *<b>not</b>* cause the SVSM to run. So I’d suggest perhaps rephrasing this to clarify this a bit more.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">p.2: “The hypervisor is expected to cause the SVSM to run any time delivery of an<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">interrupt would result in injection of #HV to the SVSM.”<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This is just basic Restricted Injection behavior I believe…in order to send an interrupt to the SVSM the HV must inject a #HV into the SVSM and then run it. I don’t think any of that changes with this Alternate
Injection spec (right?)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">p.2: “Whenever the hypervisor delivers an interrupt for a lower VMPL (or an event, such as a request to<o:p></o:p></span></i></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">revert to host-managed APIC emulation), it will set the appropriate interrupt bit(s) in the extended<o:p></o:p></span></i></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">interrupt descriptor corresponding to the lower VMPL, and it will also set bit 1, 2, or 3 in the second<o:p></o:p></span></i></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">16-bit word of the SVSM’s extended interrupt descriptor to indicate which VMPL has pending<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">interrupt evaluation work.”<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Shouldn’t this be bits 8, 9, or 10?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">p.3 extended interrupt descriptor<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I would suggest considering defining names for each of these fields, and including a table showing the overall layout. The spec currently refers to fields exclusively by bit position, which I personally found
a bit hard to parse. For instance, if bits 7:0 were named “SINGLE_VEC” (or whatever you’d like), then later in the section you could refer to that instead of referring to bits 7:0.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">p.4:
</span></i><i><span style="font-size:11.0pt">If the SVSM does know that the first component to execute will support the SVSM APIC Protocol, then<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">it may enable Alternate Injection prior to the first guest entry;</span></i><i><span style="font-size:11.0pt"><o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The statement about the SVSM having to know if the first component supports Alternate Injection is for security, correct? That is, if the guest wants interrupt security then it’ll want Alternate Injection
enabled from the beginning. If that’s the case, then the SVSM *<b>must</b>* enable Alternate Injection prior to the first guest entry (not “may”) true?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">p.5 (Enabled/Locked/Disabled) state machine<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I found this a bit confusing (at a minimum I’d politely request a diagram showing state transitions). Usually “Locked” means you can’t change, but in this case, the Disabled state seems to be more locked
than the Locked state.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I had to read the part about the flows several times to understand it. I think I get it now, but I am concerned about the fact that once Disabled, Alternate Injection can’t be re-enabled. Is that really
required? For instance, what if we’re running a guest OS that doesn’t understand alternate injection and then we kexec into a kernel that does.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Another idea to consider: What if you had a counter that increments when someone requested Alternate Injection and decremented when they asked to disable it. And the feature is enabled when the counter is
> 0. I think that would also solve your problem of guest FW not knowing if the guest OS will want the feature or not.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">For example: SVSM knows guest FW supports AlternateInjection so it starts the counter at 1. The guest OS also supports it so it asks for it to be enabled raising the counter to 2. Then guest FW disables
Alternate Injection in ExitBootServices, decrementing the counter back to 1 so it stays enabled.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">p. 5: “</span></i><i><span style="font-size:11.0pt">Consequently, the SVSM must be designed so that once it passes the point where<o:p></o:p></span></i></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">it commits to entering the lower VMPL, any delivery of #HV that indicates interrupt delivery to the<o:p></o:p></span></i></p>
<p class="MsoNormal" style="text-autospace:none"><i><span style="font-size:11.0pt">lower VMPL will cause it to cancel the VMGEXIT that would cause a return to the lower VMPL, so<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">that it can process the interrupt that has been signaled.”</span></i><i><span style="font-size:11.0pt"><o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This probably a bit unrelated to the spec itself as this is really about the internal implementation of the SVSM. But I think the important point is that the SVSM may be running (for whatever reason), the
HV can send it a #HV, and then when the SVSM requests a VMPL change the HV should assume that the SVSM has processed the information from the #HV.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">p.6 Disable Alternate Injection<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Minor clarification but I would say that this simply disables Alternate Injection but doesn’t necessarily require the HV to deliver events to the guest using direct event injection. There are other interrupt
delivery mechanisms too (including Secure AVIC as described in APM vol2). So I’d perhaps suggest just saying that the HV has to deliver any events through other means, not necessarily direct event injection.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I think that’s all I saw for now, the actual protocol itself seemed to make sense, but I’m guessing others may have feedback there. And again, really appreciate the work on putting this together!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks –David Kaplan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> AMD-SEV-SNP <amd-sev-snp-bounces+david.kaplan=amd.com@lists.suse.com>
<b>On Behalf Of </b>Jon Lange<br>
<b>Sent:</b> Thursday, May 16, 2024 11:40 PM<br>
<b>To:</b> amd-sev-snp@lists.suse.com; svsm-devel@coconut-svsm.dev<br>
<b>Subject:</b> RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%">
<tbody>
<tr>
<td style="background:#FFB900;padding:5.0pt 2.0pt 5.0pt 2.0pt"></td>
<td width="100%" style="width:100.0%;background:#FFF8E5;padding:5.0pt 4.0pt 5.0pt 12.0pt">
<div>
<p class="MsoNormal" style="mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly">
<b><span style="color:#222222">Caution:</span></b><span style="color:#222222"> This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
<o:p></o:p></span></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif">Attached is a specification I am proposing to handle support for Alternate Injection in SNP guests through the use of an SVSM. This document proposes changes to the AMD GHCB specification
and to the AMD SVSM specification to enable the negotiation required to make Alternate Injection work correctly.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif">Support for this protocol will not be possible in KVM until KVM is able to include native support for multiple VMPLs with separate interrupt sources for each. That work is underway
elsewhere, and my expectation is that this proposed specification will align with the capabilities that KVM will be introducing as part of the multi-VMPL support.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif">I will be submitting changes to COCONUT-SVSM to implement this protocol. I welcome all feedback to the spec, and will update the code to match whatever spec changes are agreed
upon.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif">-Jon<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>