On 4/15/21 11:09 AM, Paolo Bonzini wrote:
> On 07/04/21 20:00, Tom Lendacky wrote:
>> For the series:
>>
>> Acked-by: Tom Lendacky
>
> Shall I take this as a request (or permission, whatever :)) to merge it
> through the KVM tree?
Adding Herbert. Here'
On 4/9/21 9:38 AM, Tom Lendacky wrote:
> From: Tom Lendacky
>
> Access to the GHCB is mainly in the VMGEXIT path and it is known that the
> GHCB will be mapped. But there are two paths where it is possible the GHCB
> might not be mapped.
>
> The sev_vcpu_deliver_
On 4/8/21 2:48 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>
>>
>> On 4/8/21 12:37 PM, Sean Christopherson wrote:
>>> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>>> On 4/8/21 12:10 PM, Sean Christopherson wrote:
>
From: Tom Lendacky
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold
On 4/8/21 12:37 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>> On 4/8/21 12:10 PM, Sean Christopherson wrote:
>>> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>>
On 4/8/21 12:10 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> Access to the GHCB is mainly in the VMGEXIT path and it is known that the
>> GHCB will be mapped. But there are two paths where it is possible the
On 4/7/21 2:45 PM, Ramakrishna Saripalli wrote:
> From: Ramakrishna Saripalli
>
> Expose Predictive Store Forwarding capability to guests.
> Guests enable or disable PSF via SPEC_CTRL MSR.
>
> Signed-off-by: Ramakrishna Saripalli
> ---
> arch/x86/kvm/cpuid.c | 4 +++-
> 1 file changed, 3
From: Tom Lendacky
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold
On 4/8/21 11:14 AM, Paolo Bonzini wrote:
> On 08/04/21 18:04, Tom Lendacky wrote:
>>>>> + if (!err || !sev_es_guest(vcpu->kvm) ||
>>>>> !WARN_ON_ONCE(svm->ghcb))
>>>> This should be WARN_ON_ONCE(!svm->ghcb), otherwise you'll get th
On 4/7/21 4:07 PM, Sean Christopherson wrote:
> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>> On 4/7/21 3:08 PM, Sean Christopherson wrote:
>>> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>>>> From: Tom Lendacky
>>>>
>>>> The sev_vcpu_delive
On 4/7/21 2:45 PM, Borislav Petkov wrote:
> On Wed, Apr 07, 2021 at 01:25:55PM +0200, Borislav Petkov wrote:
>> On Tue, Apr 06, 2021 at 02:42:43PM -0500, Tom Lendacky wrote:
>>> The GHCB spec only defines the "0" reason code set. We could provide Linux
>>> it
On 4/7/21 3:08 PM, Sean Christopherson wrote:
> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
>> the caller of the AP Reset Hold NAE event that a SIPI has been deliv
From: Tom Lendacky
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB may not be mapped, which will result
arch/x86/kvm/svm/sev.c | 262 +--
> drivers/crypto/ccp/sev-dev.c | 197 +++++-
> drivers/crypto/ccp/sev-dev.h | 4 +-
> 3 files changed, 196 insertions(+), 267 deletions(-)
For the series:
Acked-by: Tom Lendacky
>
On 4/7/21 12:34 PM, Brijesh Singh wrote:
>
> On 4/7/21 6:59 AM, Borislav Petkov wrote:
>> On Wed, Mar 24, 2021 at 11:44:18AM -0500, Brijesh Singh wrote:
>>> The SEV-SNP guest is required to perform GHCB GPA registration. This is
>> Why does it need to do that? Some additional security so as to
On 4/7/21 8:35 AM, Brijesh Singh wrote:
>
> On 4/7/21 6:16 AM, Borislav Petkov wrote:
>> On Tue, Apr 06, 2021 at 10:47:18AM -0500, Brijesh Singh wrote:
>>> Before the GHCB is established the caller does not need to save and
>>> restore MSRs. The page_state_change() uses the GHCB MSR protocol and
On 4/6/21 10:47 AM, Brijesh Singh wrote:
>
> On 4/6/21 5:33 AM, Borislav Petkov wrote:
>> On Wed, Mar 24, 2021 at 11:44:17AM -0500, Brijesh Singh wrote:
>>
...
>> *Any* and *all* page state changes which fail immediately terminate a
>> guest? Why?
>
>
> The hypervisor uses the RMPUPDATE
On 4/6/21 9:33 AM, Dave Hansen wrote:
> On 4/6/21 12:44 AM, David Hildenbrand wrote:
>> On 02.04.21 17:26, Kirill A. Shutemov wrote:
>>> TDX architecture aims to provide resiliency against confidentiality and
>>> integrity attacks. Towards this goal, the TDX architecture helps enforce
>>> the
On 4/5/21 11:33 AM, Sean Christopherson wrote:
> On Mon, Apr 05, 2021, Tom Lendacky wrote:
>> On 4/2/21 6:36 PM, Sean Christopherson wrote:
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index 6556d220713b..4c513318f16a 100644
>&
-zero length and are not known to the kernel. This is not an
> explicit goal, but arguably the side effect is a good thing from the
> kernel's perspective.
>
> Cc: Brijesh Singh
> Cc: Borislav Petkov
> Cc: Tom Lendacky
> Signed-off-by: Sean Christopherson
> ---
>
("x86: Add support for changing memory encryption
> attribute in early boot")
> Reviewed-by: Kirill A. Shutemov
> Signed-off-by: Isaku Yamahata
Reviewed-by: Tom Lendacky
> ---
> arch/x86/mm/mem_encrypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
the SME path. This will fail, but it is also not considered
> a problem because non-encrypted guests have no protection
> against the hypervisor anyway.
>
> Signed-off-by: Joerg Roedel
Acked-by: Tom Lendacky
> ---
> arch/x86/boot/compressed/mem_encryp
On 3/12/21 2:51 PM, Sean Christopherson wrote:
On Fri, Mar 12, 2021, Vipin Sharma wrote:
On Thu, Mar 11, 2021 at 07:59:03PM +0100, Michal Koutný wrote:
+#ifndef CONFIG_KVM_AMD_SEV
+/*
+ * When this config is not defined, SEV feature is not supported and APIs in
+ * this file are not used but
se positives for is_shadow_present_spte(), which lead to a variety
> of fireworks, crashes KVM, and likely hangs the host kernel.
>
> Fixes: b14e28f37e9b ("KVM: x86/mmu: Use a dedicated bit to track
> shadow/MMU-present SPTEs")
> Reported-by: Tom Lendacky
Fixes the issue
On 3/9/21 2:11 AM, Rijo Thomas wrote:
> The first patch helps to improve the response time by reducing the
> polling time of the tee command status variable.
>
> Second patch is a bug fix to handle multi-threaded use-case.
> During testing, race condition was seen due to missing synchronisation
>
On 3/9/21 2:11 AM, Rijo Thomas wrote:
> Update the copyright year for PSP TEE driver files.
>
> Signed-off-by: Rijo Thomas
The copyright updates really should occur as part of the changes in the
other patches vs a separate patch.
Thanks,
Tom
> ---
> drivers/crypto/ccp/tee-dev.c | 2 +-
>
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 229164175ff0c61ff581e6bf37fbfcb608b6e9bb
Gitweb:
https://git.kernel.org/tip/229164175ff0c61ff581e6bf37fbfcb608b6e9bb
Author:Tom Lendacky
AuthorDate:Thu, 04 Mar 2021 16:40:11 -06:00
Committer
On 2/25/21 2:47 PM, Sean Christopherson wrote:
> Introduce MMU_PRESENT to explicitly track which SPTEs are "present" from
> the MMU's perspective. Checking for shadow-present SPTEs is a very
> common operation for the MMU, particularly in hot paths such as page
> faults. With the addition of
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 9da54be651f8a856d9e6c14183d0df948e222103
Gitweb:
https://git.kernel.org/tip/9da54be651f8a856d9e6c14183d0df948e222103
Author:Tom Lendacky
AuthorDate:Thu, 04 Mar 2021 16:40:11 -06:00
Committer
From: Tom Lendacky
An SEV guest requires that virtio devices use the DMA API to allow the
hypervisor to successfully access guest memory as needed.
The VIRTIO_F_VERSION_1 and VIRTIO_F_ACCESS_PLATFORM features tell virtio
to use the DMA API. Add arch_has_restricted_virtio_memory_access() for
x86
From: Tom Lendacky
If SEV has been disabled (e.g. through BIOS), the driver probe will still
issue SEV firmware commands. The SEV INIT firmware command will return an
error in this situation, but the error code is a general error code that
doesn't highlight the exact reason.
Add a check
On 2/24/21 9:44 PM, Steve Rutherford wrote:
On Wed, Feb 24, 2021 at 1:00 AM Nathan Tempelman wrote:
@@ -1186,6 +1195,10 @@ int svm_register_enc_region(struct kvm *kvm,
if (!sev_guest(kvm))
return -ENOTTY;
+ /* If kvm is mirroring encryption context it isn't
On 2/10/21 10:47 AM, Dave Hansen wrote:
On 2/10/21 2:21 AM, Joerg Roedel wrote:
+ /* Store to memory and keep it in the registers */
+ movl%eax, rva(sev_check_data)(%ebp)
+ movl%ebx, rva(sev_check_data+4)(%ebp)
+
+ /* Enable paging to see if encryption is active
On 2/3/21 6:39 PM, Ashish Kalra wrote:
From: Brijesh Singh
The ioctl is used to retrieve a guest's shared pages list.
...
+int svm_get_shared_pages_list(struct kvm *kvm,
+ struct kvm_shared_pages_list *list)
+{
+ struct kvm_sev_info *sev =
On 2/3/21 6:38 PM, Ashish Kalra wrote:
From: Brijesh Singh
This hypercall is used by the SEV guest to notify a change in the page
encryption status to the hypervisor. The hypercall should be invoked
only when the encryption attribute is changed from encrypted -> decrypted
and vice versa. By
e the performance hit by running some benchmark
>> with virtio-net/virtio-blk/virtio-rng.
>>
>> Earlier I said:
>>>> Another possibility is to move this hardening to the common virtio code,
>>>> but I think the code may become more complicated there since it
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 62a08a7193dc9107904aaa51a04ba3ba2959f745
Gitweb:
https://git.kernel.org/tip/62a08a7193dc9107904aaa51a04ba3ba2959f745
Author:Tom Lendacky
AuthorDate:Mon, 01 Feb 2021 12:26:27 -06:00
Committer
On 2/1/21 12:26 PM, Tom Lendacky wrote:
From: Tom Lendacky
Under the GHCB specification, SEV-ES guests can support string I/O. The
current #VC handler contains this support, so remove the need to unroll
kernel string I/O operations. This will reduce the number of #VC
exceptions generated
From: Tom Lendacky
Under the GHCB specification, SEV-ES guests can support string I/O. The
current #VC handler contains this support, so remove the need to unroll
kernel string I/O operations. This will reduce the number of #VC
exceptions generated as well as the number VMEXITS for the guest
On 1/27/21 3:54 PM, Sean Christopherson wrote:
On Wed, Jan 27, 2021, Peter Gonda wrote:
Grab kvm->lock before pinning memory when registering an encrypted
region; sev_pin_memory() relies on kvm->lock being held to ensure
correctness when checking and updating the number of pinned pages.
...
I'm not exactly sure what the problem is that your fixing? What is the
symptom that you're seeing?
>
> Tested: Booted SEV enabled VM on host.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Paolo Bonzini
> Cc: Joerg Roedel
&g
that additional state being provided.
Yes, that's true.
I'm ok with removing the tracking if that's desired. Otherwise, we can add
a vcpu->arch.regs_dirty = 0 in sev_es_sync_from_ghcb().
Thanks,
Tom
>
> Cc: Brijesh Singh
> Cc: Tom Lendacky
> Fixes: 291bd20d5d88 ("KVM
, and exits early if not. And
sev_es_sync_from_ghcb() is only called if the GHCB has been successfully
mapped. The only thing in between is sev_es_validate_vmgexit(), which will
terminate the VM on error. So I don't think this patch is needed.
Thanks,
Tom
Cc: Brijesh Singh
Cc: Tom Lendacky
Signed
V wouldn't be marked as enabled in KVM if
SEV_INIT fails, but that's a problem for another day.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm
, and CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT has the
unfortunate side effect of enabling all the SEV-ES _guest_ code due to
it being dependent on CONFIG_AMD_MEM_ENCRYPT=y.
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: Brijesh Singh
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch
svm_sev_enabled() in favor of using the global
'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid,
which is true even if KVM setup fails, 'sev' will be true if and only
if KVM setup fully succeeds.
Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations")
Cc: Tom Lendac
On 1/21/21 9:55 AM, Tejun Heo wrote:
Hello,
On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
the SEV firmware will not allow the activation of an SEV-ES VM to be
assigned to an ASID greater than or equal
On 1/20/21 10:40 AM, Tejun Heo wrote:
Hello,
On Tue, Jan 19, 2021 at 11:13:51PM -0800, Vipin Sharma wrote:
Can you please elaborate? I skimmed through the amd manual and it seemed to
say that SEV-ES ASIDs are superset of SEV but !SEV-ES ASIDs. What's the use
case for mixing those two?
For
On 1/18/21 12:03 PM, Paolo Bonzini wrote:
On 16/01/21 06:40, Tom Lendacky wrote:
Introduce a new Kconfig, AMD_SEV_ES_GUEST, to control the inclusion of
support for running as an SEV-ES guest. Pivoting on AMD_MEM_ENCRYPT for
guest SEV-ES support is undesirable for host-only kernel builds
A dedicated Kconfig also makes it easier to understand exactly what is
and isn't support in a given configuration.
Opportunistically update the AMD_MEM_ENCRYPT help text to note that it
also enables support for SEV guests.
Cc: Tom Lendacky
Cc: Brijesh Singh
Signed-off-by: Sean Christopherson
On 1/13/21 6:37 PM, Sean Christopherson wrote:
Skip SEV's expensive WBINVD and DF_FLUSH if there are no SEV ASIDs
waiting to be reclaimed, e.g. if SEV was never used. This "fixes" an
issue where the DF_FLUSH fails during hardware teardown if the original
SEV_INIT failed. Ideally, SEV wouldn't
On 1/13/21 6:37 PM, Sean Christopherson wrote:
Remove the forward declaration of sev_flush_asids(), which is only a few
lines above the function itself.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 1 -
1 file
created.
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 6 +++---
arch/x86/kvm/svm/svm.h | 5 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index a2c3e2d42a7f..7e14514dd083 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b
On 1/13/21 6:37 PM, Sean Christopherson wrote:
Move the allocation of the SEV VMCB array to sev.c to help pave the way
toward encapsulating SEV enabling wholly within sev.c.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm
On 1/14/21 3:37 PM, Brijesh Singh wrote:
On 1/13/21 6:37 PM, Sean Christopherson wrote:
Move the allocation of the SEV VMCB array to sev.c to help pave the way
toward encapsulating SEV enabling wholly within sev.c.
No functional change intended.
Signed-off-by: Sean Christopherson
---
On 1/13/21 6:37 PM, Sean Christopherson wrote:
Query max_sev_asid directly after setting it instead of bouncing through
its wrapper, svm_sev_enabled(). Using the wrapper is unnecessary
obfuscation.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm/svm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index f89f702b2a58..bb7b99743bea 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86
by the equivalent IS_ENABLED(CONFIG_KVM_AMD_SEV)
check in svm_sev_enabled(), which will be dropped in a future patch.
Cc: Tom Lendacky
Signed-off-by: Sean Christopherson
Reviewed by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
with guest code, e.g. the guest
side of things has already laid claim to 'sev_enabled'.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 11 +++
arch/x86/kvm/svm/svm.c | 15 +--
arch/x86/kvm/svm/svm.h | 2 --
3 files changed, 12
On 1/14/21 11:12 AM, Sean Christopherson wrote:
On Thu, Jan 14, 2021, Tom Lendacky wrote:
On 1/13/21 6:36 PM, Sean Christopherson wrote:
Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise
KVM will unnecessarily keep the bitmap when SEV is not fully enabled.
Freeing
w KVM to usurp "sev_enabled" for its own
purposes.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h | 1 -
arch/x86/mm/mem_encrypt.c | 12 +---
arch/x86/mm/mem_encrypt_identity.c |
while building the
new SEV guest.
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: Brijesh Singh
Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is
enabled")
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+),
svm_sev_enabled() in favor of using the global
'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid,
which is true even if KVM setup fails, 'sev' will be true if and only
if KVM setup fully succeeds.
Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations")
Cc: Tom Lendac
On 1/10/21 1:11 AM, Hyunwook (Wooky) Baek wrote:
Don't assume dest/source buffers are userspace addresses when manually
copying data for string I/O or MOVS MMIO, as {get,put}_user() will fail
if handed a kernel address and ultimately lead to a kernel panic.
Signed-off-by: Hyunwook (Wooky) Baek
On 1/8/21 6:47 PM, Sean Christopherson wrote:
> Replace calls to svm_sev_enabled() with direct checks on sev_enabled, or
> in the case of svm_mem_enc_op, simply drop the call to svm_sev_enabled().
> This effectively replaces checks against a valid max_sev_asid with checks
> against sev_enabled.
On 1/11/21 10:02 AM, Tom Lendacky wrote:
On 1/8/21 6:47 PM, Sean Christopherson wrote:
Use "guest" instead of "enabled" for the global "running as an SEV guest"
flag to avoid confusion over whether "sev_enabled" refers to the guest or
the host. This w
pointers).
No functional change intended.
Signed-off-by: Sean Christopherson
Acked-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 8ba93b8fa435
" for its own
purposes.
No functional change intended.
Signed-off-by: Sean Christopherson
Acked-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h | 2 +-
arch/x86/mm/mem_encrypt.c | 4 ++--
arch/x86/mm/mem_encrypt_identity.c | 2 +-
3 files changed, 4 insertions(+),
On 1/11/21 4:42 AM, Vitaly Kuznetsov wrote:
Sean Christopherson writes:
Unconditionally invoke sev_hardware_setup() when configuring SVM and
handle clearing the module params/variable 'sev' and 'sev_es' in
sev_hardware_setup(). This allows making said variables static within
sev.c and
On 1/8/21 6:47 PM, Sean Christopherson wrote:
> Unconditionally invoke sev_hardware_setup() when configuring SVM and
> handle clearing the module params/variable 'sev' and 'sev_es' in
> sev_hardware_setup(). This allows making said variables static within
> sev.c and reduces the odds of a
() function is only based on CONFIG_KVM_AMD_SEV and
max_sev_asid. So sev_hardware_teardown() should still free everything if
it was allocated since we never change max_sev_asid, no?
Thanks,
Tom
Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations")
Cc: Tom Lendack
On 1/7/21 12:13 PM, Paolo Bonzini wrote:
On 04/01/21 21:20, Tom Lendacky wrote:
From: Tom Lendacky
Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
where the guest vCPU register state is updated and then the vCPU is VMRUN
to begin execution of the AP. For an SEV-ES
On 1/7/21 9:32 AM, Tom Lendacky wrote:
On 1/5/21 11:20 AM, Sean Christopherson wrote:
On Tue, Jan 05, 2021, Michael Roth wrote:
@@ -3703,16 +3688,9 @@ static noinstr void svm_vcpu_enter_exit(struct
kvm_vcpu *vcpu,
if (sev_es_guest(svm->vcpu.kvm)) {
__svm_sev_es_vcpu_run(
] AMD64 Architecture Programmer's Manual, Rev 3.33, Volume 2, Appendix B,
Table B-2
[2] AMD64 Architecture Programmer's Manual, Rev 3.31, Volume 3, Chapter 4,
VMSAVE/VMLOAD
[3] Secure Virtual Machine Architecture Reference Manual, Rev 3.01
Suggested-by: Tom Lendacky
Signed-off-by: Michael Roth
On 1/5/21 11:20 AM, Sean Christopherson wrote:
On Tue, Jan 05, 2021, Michael Roth wrote:
@@ -3703,16 +3688,9 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu
*vcpu,
if (sev_es_guest(svm->vcpu.kvm)) {
__svm_sev_es_vcpu_run(svm->vmcb_pa);
} else {
-
From: Tom Lendacky
Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
where the guest vCPU register state is updated and then the vCPU is VMRUN
to begin execution of the AP. For an SEV-ES guest, this won't work because
the guest register state is encrypted.
Following
On 12/15/20 2:25 PM, Tom Lendacky wrote:
On 12/14/20 1:46 PM, Tom Lendacky wrote:
On 12/14/20 10:03 AM, Paolo Bonzini wrote:
On 10/12/20 18:10, Tom Lendacky wrote:
From: Tom Lendacky
+case SVM_VMGEXIT_AP_HLT_LOOP:
+svm->ap_hlt_loop = true;
This value needs to be communica
On 12/22/20 4:31 PM, Babu Moger wrote:
Newer AMD processors have a feature to virtualize the use of the
SPEC_CTRL MSR. A hypervisor may wish to impose speculation controls on
guest execution or a guest may want to impose its own speculation
controls. Therefore, the processor implements both host
On 12/23/20 11:42 AM, Borislav Petkov wrote:
From: Borislav Petkov
Hi,
here's v1 with the requested change to return -ENODATA on short input to
the decoder. The rest is as in the previous submission.
Only lightly tested.
Thx.
changelog:
==
That is, provided this is how we want to
On 12/10/20 11:10 AM, Tom Lendacky wrote:
> From: Tom Lendacky
>
> An SEV-ES guest is started by invoking a new SEV initialization ioctl,
> KVM_SEV_ES_INIT. This identifies the guest as an SEV-ES guest, which is
> used to drive the appropriate ASID allocation, VMSA encryption,
On 12/14/20 1:46 PM, Tom Lendacky wrote:
> On 12/14/20 10:03 AM, Paolo Bonzini wrote:
>> On 10/12/20 18:10, Tom Lendacky wrote:
>>> From: Tom Lendacky
>>>
>>> +case SVM_VMGEXIT_AP_HLT_LOOP:
>>> +svm->ap_hlt_loop = true;
>>
>&
On 12/14/20 12:13 PM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> This patch series provides support for running SEV-ES guests under KVM.
>>
>
> I'm queuing everything except patch 27, there's time to include it lat
On 12/14/20 12:32 PM, Paolo Bonzini wrote:
> This will be used by SEV-ES to inject MSR failure via the GHCB.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Tom Lendacky
(Changed Sean's email on this reply, but missed the others...)
> ---
> arch/x86/include/asm/kvm_host.h |
ified nicely.
>
> Because complete_emulated_wrmsr now becomes essentially a call to
> kvm_complete_insn_gp, remove complete_emulated_msr.
>
> Signed-off-by: Paolo Bonzini
Just two minor nits below.
Reviewed-by: Tom Lendacky
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>
On 12/14/20 12:32 PM, Paolo Bonzini wrote:
> There is no need to inject a #GP from kvm_mtrr_set_msr, kvm_emulate_wrmsr will
> handle it.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Tom Lendacky
> ---
> arch/x86/kvm/mtrr.c | 6 +-
> 1 file changed, 1 inse
On 12/14/20 10:03 AM, Paolo Bonzini wrote:
> On 10/12/20 18:10, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
>> where the guest vCPU register state is updated and then the vCPU is VMRUN
>
On 12/14/20 9:49 AM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> + pr_info("SEV-ES guest requested termination: %#llx:%#llx\n",
>> + reason_set, reason_code);
>> + fallthrough;
>> + }
>
> It would
On 12/14/20 9:45 AM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> @@ -3184,6 +3186,8 @@ static int svm_invoke_exit_handler(struct vcpu_svm
>> *svm, u64 exit_code)
>> return halt_interception(svm);
>> else if (exit_code == SVM_EX
On 12/14/20 12:13 PM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> This patch series provides support for running SEV-ES guests under KVM.
>>
>
> I'm queuing everything except patch 27, there's time to include it later
On 12/14/20 9:41 AM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> Additionally, an SEV-ES guest must only and always intercept DR7 reads and
>> writes. Update set_dr_intercepts() and clr_dr_intercepts() to account for
>> this.
>
> I cannot see i
On 12/14/20 9:33 AM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> @@ -2797,7 +2838,27 @@ static int svm_set_msr(struct kvm_vcpu *vcpu,
>> struct msr_data *msr)
>> static int wrmsr_interception(struct vcpu_svm *svm)
>> {
>> - return kvm_
On 12/14/20 6:29 AM, Paolo Bonzini wrote:
> On 10/12/20 18:09, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> When both KVM support and the CCP driver are built into the kernel instead
>> of as modules, KVM initialization can happen before CCP initialization. As
>&
From: Tom Lendacky
On systems that do not have hardware enforced cache coherency between
encrypted and unencrypted mappings of the same physical page, the
hypervisor can use the VM page flush MSR (0xc001011e) to flush the cache
contents of an SEV guest page. When a small number of pages
From: Tom Lendacky
Add support to KVM for determining if a system is capable of supporting
SEV-ES as well as determining if a guest is an SEV-ES guest.
Signed-off-by: Tom Lendacky
---
arch/x86/kvm/Kconfig | 3 ++-
arch/x86/kvm/svm/sev.c | 47 ++
arch
From: Tom Lendacky
When both KVM support and the CCP driver are built into the kernel instead
of as modules, KVM initialization can happen before CCP initialization. As
a result, sev_platform_status() will return a failure when it is called
from sev_hardware_setup(), when this isn't really
From: Tom Lendacky
Update the GHCB accessor functions to add functions for retrieve GHCB
fields by name. Update existing code to use the new accessor functions.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/svm.h | 10 ++
arch/x86/kernel/cpu/vmware.c | 12 ++--
2
From: Tom Lendacky
When a guest is running under SEV-ES, the hypervisor cannot access the
guest register state. There are numerous places in the KVM code where
certain registers are accessed that are not allowed to be accessed (e.g.
RIP, CR0, etc). Add checks to prevent register accesses and add
From: Tom Lendacky
Allocate a page during vCPU creation to be used as the encrypted VM save
area (VMSA) for the SEV-ES guest. Provide a flag in the kvm_vcpu_arch
structure that indicates whether the guest state is protected.
When freeing a VMSA page that has been encrypted, the cache contents
From: Tom Lendacky
Add trace events for entry to and exit from VMGEXIT processing. The vCPU
id and the exit reason will be common for the trace events. The exit info
fields will represent the input and output values for the entry and exit
events, respectively.
Signed-off-by: Tom Lendacky
From: Tom Lendacky
Since the guest register state of an SEV-ES guest is encrypted, debugging
is not supported. Update the code to prevent guest debugging when the
guest has protected state.
Additionally, an SEV-ES guest must only and always intercept DR7 reads and
writes. Update
1 - 100 of 2307 matches
Mail list logo
