<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Georgia",serif;
color:blue;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:148206641;
mso-list-type:hybrid;
mso-list-template-ids:-1511983720 -860045930 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">The registration status of Alternate Injection applies to the entire guest, but the Alternate Injection SEV feature is per-VCPU. There has to be something to tie the
two together. Consider an example where OVMF elects to deregister Alternate Injection during ExitBootServices because it does not know (and cannot know) what the loaded OS is going to do, and additionally suppose that the loaded OS in this case has not registered
Alternate Injection. That means when OVMF deregisters as part of ExitBootServices (presumably on the BSP), it will make the 0b01 call, which will deregister Alternate Injection at a VM level (meaning it cannot be re-registered), but only the BSP’s VMSA will
have the SEV feature bit clear. Once OVMF deregisters Alternate Injection, it must ensure that any AP that is already running issues the 0b00 form of the call to refresh its own SEV feature to bring it into sync with the VM-wide registration state. In this
example, each AP that issues the call will cause Alternate Injection to be removed from its VMSA. On the other hand, if Alternate Injection were to remain registered because the loaded OS chose to register it, then the 0b00 call would have no effect on each
AP because Alternate Injection remains registered at the VM level. Thus this call is both safe and necessary on every AP to align each AP with the VM-wide status. I can try to make this more clear in the next revision.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Call 5 is erroneous and should be removed – the intended text was included in Call 1 as you suspected. I’ll clean that up in the next revision.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">-Jon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<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"> Kaplan, David <David.Kaplan@amd.com>
<br>
<b>Sent:</b> Monday, June 3, 2024 11:46 AM<br>
<b>To:</b> Jon Lange <jlange@microsoft.com>; amd-sev-snp@lists.suse.com; svsm-devel@coconut-svsm.dev<br>
<b>Subject:</b> [EXTERNAL] RE: RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:5.0pt"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:blue">[AMD Official Use Only - AMD Internal Distribution Only]<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks Jon, I had no issues opening this version.<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 did have some questions though on the new registration protocol. The description on p.4-5 makes sense but makes it sounds like there are only 2 types of calls here (‘register’ and ‘unregister’), yet the
detailed SVSM_APIC_CONFIGURE_EMULATION on p.8 has 3 different inputs.<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 can’t quite figure out the 0b00 call…it sounded like AlternateInjection would be automatically disabled via the 01 call if the registration count drops to 0. So when would the 00 call be used?<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">Separately, on p. 10, call 5 (Configure Alternate Injection) seems to be missing some text. I’m guessing maybe that call is redundant with call 1 and intended to be removed but it’s unclear.<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"> Jon Lange <<a href="mailto:jlange@microsoft.com">jlange@microsoft.com</a>>
<br>
<b>Sent:</b> Monday, June 3, 2024 12:47 PM<br>
<b>To:</b> Kaplan, David <<a href="mailto:David.Kaplan@amd.com">David.Kaplan@amd.com</a>>;
<a href="mailto:amd-sev-snp@lists.suse.com">amd-sev-snp@lists.suse.com</a>; <a href="mailto:svsm-devel@coconut-svsm.dev">
svsm-devel@coconut-svsm.dev</a><br>
<b>Subject:</b> RE: RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:5.0pt"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:blue">[AMD Official Use Only - AMD Internal Distribution Only]<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<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>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Apparently the last version of the PDF I sent had some rights restrictions. Here is a newer version which should be unrestricted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">-Jon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<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"> Jon Lange
<br>
<b>Sent:</b> Thursday, May 30, 2024 9:32 PM<br>
<b>To:</b> Kaplan, David <</span><a href="mailto:David.Kaplan@amd.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">David.Kaplan@amd.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>;
</span><a href="mailto:amd-sev-snp@lists.suse.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">amd-sev-snp@lists.suse.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">;
</span><a href="mailto:svsm-devel@coconut-svsm.dev"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">svsm-devel@coconut-svsm.dev</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> RE: RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Attached is a newer draft (dated May 24) of the Alternate Injection proposal that incorporates the concepts in the discussion referenced below. The most significant
design change is the change to a registration count to determine if and when Alternate Injection should be disabled as the result of a hand-off from firmware to the OS.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">There is an open PR in the COCONUT-SVSM project that includes the SVSM implementation of this proposal.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">-Jon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<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"> Jon Lange
<br>
<b>Sent:</b> Thursday, May 23, 2024 3:05 PM<br>
<b>To:</b> Kaplan, David <</span><a href="mailto:David.Kaplan@amd.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">David.Kaplan@amd.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>;
</span><a href="mailto:amd-sev-snp@lists.suse.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">amd-sev-snp@lists.suse.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">;
</span><a href="mailto:svsm-devel@coconut-svsm.dev"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">svsm-devel@coconut-svsm.dev</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> RE: RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">David, thanks for your feedback!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l0 level1 lfo1">
<span style="font-size:11.0pt;color:windowtext">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.</span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Yes, this is what I meant by deliverable, and I now see why this caused confusion because the CPU defines “deliverable” to mean when the IDT dispatch can occur, which
is different. I can clarify this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1;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 interrupt would result in injection of #HV to the SVSM.”<o:p></o:p></span></i></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><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></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">This is made more complex by the presence of multiple VMPLs, where I don’t think we have any clear specification (including in Restricted Injection documentation) about
scheduling considerations. The point here is that whenever the process of delivering an interrupt to a lower VMPL makes the hypervisor conclude that a notification is due to the SVSM, then the SVSM (i.e. VMPL 0) must be selected to run next on that vCPU.
I’m encouraged that you think this should be implicit from existing language, but that was less obvious to me.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt">Shouldn’t this be bits 8, 9, or 10?<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">This is an editing error from a previous draft. Thanks for pointing it out.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l0 level1 lfo1">
<span style="font-size:11.0pt;color:windowtext">I would suggest considering defining names for each of these fields, and including a table showing the overall layout. </span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">I agree that this should happen once this behavior is incorporated into the GHCB/SVSM specifications owned by AMD. My aim here was to describe the behavior and the standards
changes required, not to create authoritative documentation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><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></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">I think this is another leftover from previous revisions. I agree that this must be stated more clearly.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l0 level1 lfo1">
<span style="font-size:11.0pt;color:windowtext">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.</span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">This is a great idea and eliminates all of the Enabled/Disabled/Locked confusion that you were concerned about. I will plan to make this change, which I think will make
your feedback about the Enabled/Disabled/Locked state machine moot.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><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></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Yes, but this fact is not necessarily obvious to someone who implements the SVSM protocol. I thought it would be helpful to point out, but it need not be part of the
text that is incorporated into the SVSM specification. It’s also helpful to underscore it here because the protocol could alternately have been designed to state that it was the hypervisor’s responsibility to prevent the VMPL switch if the #HV NoFurtherSignal
bit was still set (meaning the pending interrupt had not yet been processed) – so stating the SVSM’s responsibility here in the document emphasizes the fact that the tradeoff has been considered and the responsibility lies with the SVSM and not the hypervisor.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l0 level1 lfo1">
<span style="font-size:11.0pt;color:windowtext">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.</span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">Reenabling Alternate Injection would require transferring all of the APIC state from the hypervisor to the SVSM – not just the IRR, but the ISR and TMR – so the future
uses of the protocol can correctly apply to any interrupts that are already in service. This introduces complexity that strikes me as unnecessary – or at least not compelling enough to be worth it – given that once Alternate Injection is disabled, the security
state of the guest has regressed and the absolute promise of “no host interference” no longer applies. Once that promise is gone – i.e., once the guest accepts that it can be placed into a vulnerable posture – it’s not clear to me why it’s compelling to return
to a more roust posture. I would suggest proceeding without this capability, and if it becomes important, then it can be added in a future version of the specification.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:blue;margin-left:0in;mso-list:l0 level1 lfo1">
<span style="font-size:11.0pt;color:windowtext">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).</span><span style="font-size:10.0pt;font-family:"Georgia",serif"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">This spec was drafted before Secure AVIC was documented in the APM. I take your point, though it may be more effective to accomplish the clarity in the language that
is ultimately incorporated into the SVSM specficiation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue">-Jon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia",serif;color:blue"><o:p> </o:p></span></p>
<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"> Kaplan, David <</span><a href="mailto:David.Kaplan@amd.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">David.Kaplan@amd.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>
<br>
<b>Sent:</b> Thursday, May 23, 2024 10:06 AM<br>
<b>To:</b> Jon Lange <</span><a href="mailto:jlange@microsoft.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">jlange@microsoft.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>;
</span><a href="mailto:amd-sev-snp@lists.suse.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">amd-sev-snp@lists.suse.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">;
</span><a href="mailto:svsm-devel@coconut-svsm.dev"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">svsm-devel@coconut-svsm.dev</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> [EXTERNAL] RE: RFC: Alternate Injection SVSM support<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:5.0pt"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:blue">[AMD Official Use Only - AMD Internal Distribution Only]<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<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: “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: 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;<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: “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.”<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 <</span><a href="mailto:amd-sev-snp-bounces+david.kaplan=amd.com@lists.suse.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">amd-sev-snp-bounces+david.kaplan=amd.com@lists.suse.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>
<b>On Behalf Of </b>Jon Lange<br>
<b>Sent:</b> Thursday, May 16, 2024 11:40 PM<br>
<b>To:</b> </span><a href="mailto:amd-sev-snp@lists.suse.com"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">amd-sev-snp@lists.suse.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">;
</span><a href="mailto:svsm-devel@coconut-svsm.dev"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">svsm-devel@coconut-svsm.dev</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><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>
</div>
</div>
</div>
</div>
</body>
</html>