> Co-developed-by: Sean Christopherson
> Signed-off-by: Sean Christopherson
> Co-developed-by: Pratik R. Sampat
> Signed-off-by: Pratik R. Sampat
> Signed-off-by: Ashish Kalra
One comment below, otherwise:
Reviewed-by: Tom Lendacky
> ---
> arch/x86/kvm/svm/sev.c | 44
On 5/9/25 12:52, Kalra, Ashish wrote:
>
> On 5/9/2025 12:01 PM, Paluri, PavanKumar wrote:
>>
>>
>> On 5/8/2025 5:52 PM, Ashish Kalra wrote:
>>> From: Ashish Kalra
>>>
>>> During platform init, SNP initialization may fail for several reasons,
>>> such as firmware command failures and incompatible
On 5/8/25 17:52, Ashish Kalra wrote:
> From: Ashish Kalra
>
> During platform init, SNP initialization may fail for several reasons,
> such as firmware command failures and incompatible versions. However,
> the KVM capability may continue to advertise support for it.
>
> The platform may have SN
On 3/10/25 05:26, Borislav Petkov wrote:
> On Thu, Dec 19, 2024 at 11:44:00AM +, Ajay Kaher wrote:
>> For VMware hypervisor, SEV-SNP enabled VM's could boot without UEFI.
>> In this case, mpparse_find_mptable() has to be called to parse MP
>> tables which contains boot information.
>>
>> Fixes:
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_sipi_
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 inser
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 g
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 delivere
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 in a
d structures on local stack
>
> 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 not
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 i
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 instru
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 enabl
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
>&
on-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
>
ot;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(-)
>
>
to
> 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/
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 th
ositives 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 +-
> driv
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 "rem
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 chec
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 res
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 = &to_kvm_svm(k
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 def
copied
>> bytes. I could try to measure 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
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 as
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
st not rely on 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
> Fix
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
S
y, SEV 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
FIG_KVM_AMD_SEV, 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 Le
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&q
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 to
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 exa
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 as
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 Christoph
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 b
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
---
arch/
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
masked 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(+),
odds of a collision 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
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 the
will also allow 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
time 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&q
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. se
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
m_sev_info 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 8b
" 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 reduces
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 collisio
abled() 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 Le
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(
x27; does not overwrite any fields written by
'vmsave'. This has also been confirmed through testing (for the above
CPU, at least).
[1] AMD64 Architecture Programmer's Manual, Rev 3.33, Volume 2, Appendix B,
Table B-2
[2] AMD64 Architecture Programmer's Manual, Rev 3.31, Volu
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.
Followin
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 c
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 incl
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
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 be n
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 includ
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)
>> {
>> - re
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 are
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 real
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
1 - 100 of 1005 matches
Mail list logo
