<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/arch/x86/include/uapi/asm/svm.h, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/arch/x86/include/uapi/asm/svm.h?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/arch/x86/include/uapi/asm/svm.h?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-04-07T14:47:12Z</updated>
<entry>
<title>x86/sev: Provide support for SNP guest request NAEs</title>
<updated>2022-04-07T14:47:12Z</updated>
<author>
<name>Brijesh Singh</name>
<email>brijesh.singh@amd.com</email>
</author>
<published>2022-03-07T21:33:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d5af44dde5461d125d1602ac913ab5c6bdf09b8b'/>
<id>urn:sha1:d5af44dde5461d125d1602ac913ab5c6bdf09b8b</id>
<content type='text'>
Version 2 of GHCB specification provides SNP_GUEST_REQUEST and
SNP_EXT_GUEST_REQUEST NAE that can be used by the SNP guest to
communicate with the PSP.

While at it, add a snp_issue_guest_request() helper that will be used by
driver or other subsystem to issue the request to PSP.

See SEV-SNP firmware and GHCB spec for more details.

Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lore.kernel.org/r/20220307213356.2797205-42-brijesh.singh@amd.com
</content>
</entry>
<entry>
<title>x86/sev: Use SEV-SNP AP creation to start secondary CPUs</title>
<updated>2022-04-06T15:06:49Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2022-03-07T21:33:32Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0afb6b660a6b58cb336d1175ed687bf9525849a4'/>
<id>urn:sha1:0afb6b660a6b58cb336d1175ed687bf9525849a4</id>
<content type='text'>
To provide a more secure way to start APs under SEV-SNP, use the SEV-SNP
AP Creation NAE event. This allows for guest control over the AP register
state rather than trusting the hypervisor with the SEV-ES Jump Table
address.

During native_smp_prepare_cpus(), invoke an SEV-SNP function that, if
SEV-SNP is active, will set/override apic-&gt;wakeup_secondary_cpu. This
will allow the SEV-SNP AP Creation NAE event method to be used to boot
the APs. As a result of installing the override when SEV-SNP is active,
this method of starting the APs becomes the required method. The override
function will fail to start the AP if the hypervisor does not have
support for AP creation.

  [ bp: Work in forgotten review comments. ]

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lore.kernel.org/r/20220307213356.2797205-23-brijesh.singh@amd.com
</content>
</entry>
<entry>
<title>x86/mm: Validate memory when changing the C-bit</title>
<updated>2022-04-06T11:24:53Z</updated>
<author>
<name>Brijesh Singh</name>
<email>brijesh.singh@amd.com</email>
</author>
<published>2022-02-24T16:56:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=dc3f3d2474b80eaee8be89f4c5eb344f10648f42'/>
<id>urn:sha1:dc3f3d2474b80eaee8be89f4c5eb344f10648f42</id>
<content type='text'>
Add the needed functionality to change pages state from shared
to private and vice-versa using the Page State Change VMGEXIT as
documented in the GHCB spec.

Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lore.kernel.org/r/20220307213356.2797205-22-brijesh.singh@amd.com
</content>
</entry>
<entry>
<title>x86/sev: Check SEV-SNP features support</title>
<updated>2022-04-06T11:10:23Z</updated>
<author>
<name>Brijesh Singh</name>
<email>brijesh.singh@amd.com</email>
</author>
<published>2022-02-09T18:10:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cbd3d4f7c4e5a93edae68e5142a269368fde77d6'/>
<id>urn:sha1:cbd3d4f7c4e5a93edae68e5142a269368fde77d6</id>
<content type='text'>
Version 2 of the GHCB specification added the advertisement of features
that are supported by the hypervisor. If the hypervisor supports SEV-SNP
then it must set the SEV-SNP features bit to indicate that the base
functionality is supported.

Check that feature bit while establishing the GHCB; if failed, terminate
the guest.

Version 2 of the GHCB specification adds several new Non-Automatic Exits
(NAEs), most of them are optional except the hypervisor feature. Now
that the hypervisor feature NAE is implemented, bump the GHCB maximum
supported protocol version.

While at it, move the GHCB protocol negotiation check from the #VC
exception handler to sev_enable() so that all feature detection happens
before the first #VC exception.

While at it, document why the GHCB page cannot be setup from
load_stage2_idt().

  [ bp: Massage commit message. ]

Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lore.kernel.org/r/20220307213356.2797205-13-brijesh.singh@amd.com
</content>
</entry>
<entry>
<title>KVM: SVM: Software reserved fields</title>
<updated>2021-06-17T17:09:37Z</updated>
<author>
<name>Vineeth Pillai</name>
<email>viremana@linux.microsoft.com</email>
</author>
<published>2021-06-03T15:14:37Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=59d21d67f37481cfde25551ee6a467fa943812b4'/>
<id>urn:sha1:59d21d67f37481cfde25551ee6a467fa943812b4</id>
<content type='text'>
SVM added support for certain reserved fields to be used by
software or hypervisor. Add the following reserved fields:
  - VMCB offset 0x3e0 - 0x3ff
  - Clean bit 31
  - SVM intercept exit code 0xf0000000

Later patches will make use of this for supporting Hyper-V
nested virtualization enhancements.

Signed-off-by: Vineeth Pillai &lt;viremana@linux.microsoft.com&gt;
Message-Id: &lt;a1f17a43a8e9e751a1a9cc0281649d71bdbf721b.1622730232.git.viremana@linux.microsoft.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Add support for CR8 write traps for an SEV-ES guest</title>
<updated>2020-12-15T10:20:54Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2020-12-10T17:09:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d1949b93c60504b338c89cf8b3873c0d11feb7ed'/>
<id>urn:sha1:d1949b93c60504b338c89cf8b3873c0d11feb7ed</id>
<content type='text'>
For SEV-ES guests, the interception of control register write access
is not recommended. Control register interception occurs prior to the
control register being modified and the hypervisor is unable to modify
the control register itself because the register is located in the
encrypted register state.

SEV-ES guests introduce new control register write traps. These traps
provide intercept support of a control register write after the control
register has been modified. The new control register value is provided in
the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
of the guest control registers.

Add support to track the value of the guest CR8 register using the control
register write trap so that the hypervisor understands the guest operating
mode.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Message-Id: &lt;5a01033f4c8b3106ca9374b7cadf8e33da852df1.1607620209.git.thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Add support for CR4 write traps for an SEV-ES guest</title>
<updated>2020-12-15T10:20:53Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2020-12-10T17:09:57Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5b51cb13160ae0ba10645bd0a84e7847677fb6a0'/>
<id>urn:sha1:5b51cb13160ae0ba10645bd0a84e7847677fb6a0</id>
<content type='text'>
For SEV-ES guests, the interception of control register write access
is not recommended. Control register interception occurs prior to the
control register being modified and the hypervisor is unable to modify
the control register itself because the register is located in the
encrypted register state.

SEV-ES guests introduce new control register write traps. These traps
provide intercept support of a control register write after the control
register has been modified. The new control register value is provided in
the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
of the guest control registers.

Add support to track the value of the guest CR4 register using the control
register write trap so that the hypervisor understands the guest operating
mode.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Message-Id: &lt;c3880bf2db8693aa26f648528fbc6e967ab46e25.1607620209.git.thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Add support for CR0 write traps for an SEV-ES guest</title>
<updated>2020-12-15T10:20:52Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2020-12-10T17:09:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f27ad38aac23263c40fe26c0188182c129a8f8dd'/>
<id>urn:sha1:f27ad38aac23263c40fe26c0188182c129a8f8dd</id>
<content type='text'>
For SEV-ES guests, the interception of control register write access
is not recommended. Control register interception occurs prior to the
control register being modified and the hypervisor is unable to modify
the control register itself because the register is located in the
encrypted register state.

SEV-ES support introduces new control register write traps. These traps
provide intercept support of a control register write after the control
register has been modified. The new control register value is provided in
the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
of the guest control registers.

Add support to track the value of the guest CR0 register using the control
register write trap so that the hypervisor understands the guest operating
mode.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Message-Id: &lt;182c9baf99df7e40ad9617ff90b84542705ef0d7.1607620209.git.thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Add support for EFER write traps for an SEV-ES guest</title>
<updated>2020-12-15T10:20:51Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2020-12-10T17:09:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=2985afbcdbb1957a8d31992cebbc4e49d2ad8a77'/>
<id>urn:sha1:2985afbcdbb1957a8d31992cebbc4e49d2ad8a77</id>
<content type='text'>
For SEV-ES guests, the interception of EFER write access is not
recommended. EFER interception occurs prior to EFER being modified and
the hypervisor is unable to modify EFER itself because the register is
located in the encrypted register state.

SEV-ES support introduces a new EFER write trap. This trap provides
intercept support of an EFER write after it has been modified. The new
EFER value is provided in the VMCB EXITINFO1 field, allowing the
hypervisor to track the setting of the guest EFER.

Add support to track the value of the guest EFER value using the EFER
write trap so that the hypervisor understands the guest operating mode.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Message-Id: &lt;8993149352a3a87cd0625b3b61bfd31ab28977e1.1607620209.git.thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Add initial support for a VMGEXIT VMEXIT</title>
<updated>2020-12-15T10:20:47Z</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2020-12-10T17:09:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=291bd20d5d88814a73d43b55b9428feab2f28094'/>
<id>urn:sha1:291bd20d5d88814a73d43b55b9428feab2f28094</id>
<content type='text'>
SEV-ES adds a new VMEXIT reason code, VMGEXIT. Initial support for a
VMGEXIT includes mapping the GHCB based on the guest GPA, which is
obtained from a new VMCB field, and then validating the required inputs
for the VMGEXIT exit reason.

Since many of the VMGEXIT exit reasons correspond to existing VMEXIT
reasons, the information from the GHCB is copied into the VMCB control
exit code areas and KVM register areas. The standard exit handlers are
invoked, similar to standard VMEXIT processing. Before restarting the
vCPU, the GHCB is updated with any registers that have been updated by
the hypervisor.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Message-Id: &lt;c6a4ed4294a369bd75c44d03bd7ce0f0c3840e50.1607620209.git.thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
</feed>
