search for: mem_encrypt_init

...ot;); + return; + } + + /* Secure Encrypted Virtualization */ + if (sev_active()) + pr_cont(" SEV"); + + /* Encrypted Register State */ + if (sev_es_active()) + pr_cont(" SEV-ES"); + + pr_cont("\n"); +} + /* Architecture __weak replacement functions */ void __init mem_encrypt_init(void) { @@ -422,8 +447,6 @@ void __init mem_encrypt_init(void) if (sev_active()) static_branch_enable(&sev_enable_key); - pr_info("AMD %s active\n", - sev_active() ? "Secure Encrypted Virtualization (SEV)" - : "Secure Memory Encryption (SME)"); + pr...

...orm DMA * operations that might use the SWIOTLB bounce buffers. It will * mark the bounce buffers as decrypted so that their usage will * not cause "plain-text" data to be decrypted when accessed. */ mem_encrypt_init(); So, I'm wondering if creating the console device interacts in any way with the memory encryption interface? [Does basic recognition work if you start a protected virt guest with a 3270 console? I realize that the console is unlikely to work, but that should at least exercise this code path...

...orm DMA * operations that might use the SWIOTLB bounce buffers. It will * mark the bounce buffers as decrypted so that their usage will * not cause "plain-text" data to be decrypted when accessed. */ mem_encrypt_init(); So, I'm wondering if creating the console device interacts in any way with the memory encryption interface? [Does basic recognition work if you start a protected virt guest with a 3270 console? I realize that the console is unlikely to work, but that should at least exercise this code path...

...tions that might use the SWIOTLB bounce buffers. It will > > * mark the bounce buffers as decrypted so that their usage will > > * not cause "plain-text" data to be decrypted when accessed. > > */ > > mem_encrypt_init(); > > > > So, I'm wondering if creating the console device interacts in any way > > with the memory encryption interface? > > I do things a bit different than x86: the SWIOTLB stuff is set up in > mem_init(). So I think we should be fine. If there is a down-side...

...tions that might use the SWIOTLB bounce buffers. It will > > * mark the bounce buffers as decrypted so that their usage will > > * not cause "plain-text" data to be decrypted when accessed. > > */ > > mem_encrypt_init(); > > > > So, I'm wondering if creating the console device interacts in any way > > with the memory encryption interface? > > I do things a bit different than x86: the SWIOTLB stuff is set up in > mem_init(). So I think we should be fine. If there is a down-side...

...a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -19,6 +19,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT extern u64 sme_me_mask; +extern u64 sev_status; extern bool sev_enabled; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, @@ -50,6 +51,7 @@ void __init mem_encrypt_init(void); bool sme_active(void); bool sev_active(void); +bool sev_es_active(void); #define __bss_decrypted __attribute__((__section__(".bss..decrypted"))) @@ -72,6 +74,7 @@ static inline void __init sme_enable(struct boot_params *bp) { } static inline bool sme_active(void) { retu...

...x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 6f61bb93366a..d48e7be9bb49 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -48,6 +48,7 @@ int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size); void __init mem_encrypt_init(void); void __init mem_encrypt_free_decrypted_mem(void); +void __init encrypted_state_init_ghcbs(void); bool sme_active(void); bool sev_active(void); bool sev_es_active(void); @@ -71,6 +72,7 @@ static inline void __init sme_early_init(void) { } static inline void __init sme_encrypt_kernel(st...

...a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -19,6 +19,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT extern u64 sme_me_mask; +extern u64 sev_status; extern bool sev_enabled; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, @@ -50,6 +51,7 @@ void __init mem_encrypt_init(void); bool sme_active(void); bool sev_active(void); +bool sev_es_active(void); #define __bss_decrypted __attribute__((__section__(".bss..decrypted"))) @@ -72,6 +74,7 @@ static inline void __init sme_enable(struct boot_params *bp) { } static inline bool sme_active(void) { retu...

...a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -19,6 +19,7 @@ #ifdef CONFIG_AMD_MEM_ENCRYPT extern u64 sme_me_mask; +extern u64 sev_status; extern bool sev_enabled; void sme_encrypt_execute(unsigned long encrypted_kernel_vaddr, @@ -50,6 +51,7 @@ void __init mem_encrypt_init(void); bool sme_active(void); bool sev_active(void); +bool sev_es_active(void); #define __bss_decrypted __attribute__((__section__(".bss..decrypted"))) @@ -72,6 +74,7 @@ static inline void __init sme_enable(struct boot_params *bp) { } static inline bool sme_active(void) { retu...

...pt.h b/arch/x86/include/asm/mem_encrypt.h > index 6f61bb93366a..d48e7be9bb49 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -48,6 +48,7 @@ int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size); > void __init mem_encrypt_init(void); > void __init mem_encrypt_free_decrypted_mem(void); > > +void __init encrypted_state_init_ghcbs(void); > bool sme_active(void); > bool sev_active(void); > bool sev_es_active(void); > @@ -71,6 +72,7 @@ static inline void __init sme_early_init(void) { } > static in...

...gt; * operations that might use the SWIOTLB bounce buffers. It will > * mark the bounce buffers as decrypted so that their usage will > * not cause "plain-text" data to be decrypted when accessed. > */ > mem_encrypt_init(); > > So, I'm wondering if creating the console device interacts in any way > with the memory encryption interface? I do things a bit different than x86: the SWIOTLB stuff is set up in mem_init(). So I think we should be fine. If there is a down-side to calling swiotlb_update_mem_at...

..._encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 4e72b73a9cb5..c9f5df0a1c10 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -49,6 +49,7 @@ void __init mem_encrypt_free_decrypted_mem(void); /* Architecture __weak replacement functions */ void __init mem_encrypt_init(void); +void __init sev_es_init_vc_handling(void); bool sme_active(void); bool sev_active(void); bool sev_es_active(void); @@ -72,6 +73,7 @@ static inline void __init sme_early_init(void) { } static inline void __init sme_encrypt_kernel(struct boot_params *bp) { } static inline void __init s...

...x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index 6f61bb93366a..af3e58aa1603 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -48,6 +48,7 @@ int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size); void __init mem_encrypt_init(void); void __init mem_encrypt_free_decrypted_mem(void); +void __init sev_es_init_vc_handling(void); bool sme_active(void); bool sev_active(void); bool sev_es_active(void); @@ -71,6 +72,7 @@ static inline void __init sme_early_init(void) { } static inline void __init sme_encrypt_kernel(struc...

...* operations that might use the SWIOTLB bounce buffers. It will >>> * mark the bounce buffers as decrypted so that their usage will >>> * not cause "plain-text" data to be decrypted when accessed. >>> */ >>> mem_encrypt_init(); >>> >>> So, I'm wondering if creating the console device interacts in any way >>> with the memory encryption interface? >> >> I do things a bit different than x86: the SWIOTLB stuff is set up in >> mem_init(). So I think we should be fine. If ther...

From: Joerg Roedel <jroedel at suse.de> Hi, here is a rebased version of the latest SEV-ES patches. They are now based on latest tip/master instead of upstream Linux and include the necessary changes. Changes to v4 are in particular: - Moved early IDT setup code to idt.c, because the idt_descr and the idt_table are now static - This required to make stack protector work early (or

From: Joerg Roedel <jroedel at suse.de> Hi, here is the new version of the SEV-ES client enabling patch-set. It is based on the latest tip/master branch and contains the necessary changes. In particular those ar: - Enabling CR4.FSGSBASE early on supported processors so that early #VC exceptions on APs can be handled. - Add another patch (patch 1) to fix a KVM frame-size build

From: Joerg Roedel <jroedel at suse.de> Hi, here is a new version of the SEV-ES Guest Support patches for x86. The previous versions can be found as a linked list starting here: https://lore.kernel.org/lkml/20200824085511.7553-1-joro at 8bytes.org/ I updated the patch-set based on ther review comments I got and the discussions around it. Another important change is that the early IDT

From: Joerg Roedel <jroedel at suse.de> Hi, here is a new version of the SEV-ES Guest Support patches for x86. The previous versions can be found as a linked list starting here: https://lore.kernel.org/lkml/20200824085511.7553-1-joro at 8bytes.org/ I updated the patch-set based on ther review comments I got and the discussions around it. Another important change is that the early IDT

Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into