From: Borislav Petkov <bp@alien8.de>
To: Brijesh Singh <brijesh.singh@amd.com>, Vlastimil Babka <vbabka@suse.cz>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, linux-efi@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev,
linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ard Biesheuvel <ardb@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Jim Mattson <jmattson@google.com>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Dov Murik <dovmurik@linux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@ibm.com>,
Michael Roth <michael.roth@amd.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Andi Kleen <ak@linux.intel.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
tony.luck@intel.com, marcorr@google.com,
sathyanarayanan.kuppuswamy@linux.intel.com
Subject: Re: [PATCH v8 20/40] x86/sev: Use SEV-SNP AP creation to start secondary CPUs
Date: Fri, 31 Dec 2021 16:36:26 +0100 [thread overview]
Message-ID: <Yc8jerEP5CrxfFi4@zn.tnic> (raw)
In-Reply-To: <20211210154332.11526-21-brijesh.singh@amd.com>
On Fri, Dec 10, 2021 at 09:43:12AM -0600, Brijesh Singh wrote:
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index 123a96f7dff2..38c14601ae4a 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -104,6 +104,7 @@ enum psc_op {
> (((u64)(v) & GENMASK_ULL(63, 12)) >> 12)
>
> #define GHCB_HV_FT_SNP BIT_ULL(0)
> +#define GHCB_HV_FT_SNP_AP_CREATION (BIT_ULL(1) | GHCB_HV_FT_SNP)
Why is bit 0 ORed in? Because it "Requires SEV-SNP Feature."?
You can still enforce that requirement in the test though.
Or all those SEV features should not be bits but masks -
GHCB_HV_FT_SNP_AP_CREATION_MASK for example, seeing how the others
require the previous bits to be set too.
...
> static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
> DEFINE_STATIC_KEY_FALSE(sev_es_enable_key);
>
> +static DEFINE_PER_CPU(struct sev_es_save_area *, snp_vmsa);
This is what I mean: the struct is called "sev_es... " but the variable
"snp_...". I.e., it is all sev_<something>.
> +
> static __always_inline bool on_vc_stack(struct pt_regs *regs)
> {
> unsigned long sp = regs->sp;
> @@ -814,6 +818,231 @@ void snp_set_memory_private(unsigned long vaddr, unsigned int npages)
> pvalidate_pages(vaddr, npages, 1);
> }
>
> +static int snp_set_vmsa(void *va, bool vmsa)
> +{
> + u64 attrs;
> +
> + /*
> + * The RMPADJUST instruction is used to set or clear the VMSA bit for
> + * a page. A change to the VMSA bit is only performed when running
> + * at VMPL0 and is ignored at other VMPL levels. If too low of a target
What does "too low" mean here exactly?
The kernel is not at VMPL0 but the specified level is lower? Weird...
> + * VMPL level is specified, the instruction can succeed without changing
> + * the VMSA bit should the kernel not be in VMPL0. Using a target VMPL
> + * level of 1 will return a FAIL_PERMISSION error if the kernel is not
> + * at VMPL0, thus ensuring that the VMSA bit has been properly set when
> + * no error is returned.
We do check whether we run at VMPL0 earlier when starting the guest -
see enforce_vmpl0().
I don't think you need any of that additional verification here - just
assume you are at VMPL0.
> + */
> + attrs = 1;
> + if (vmsa)
> + attrs |= RMPADJUST_VMSA_PAGE_BIT;
> +
> + return rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
> +}
> +
> +#define __ATTR_BASE (SVM_SELECTOR_P_MASK | SVM_SELECTOR_S_MASK)
> +#define INIT_CS_ATTRIBS (__ATTR_BASE | SVM_SELECTOR_READ_MASK | SVM_SELECTOR_CODE_MASK)
> +#define INIT_DS_ATTRIBS (__ATTR_BASE | SVM_SELECTOR_WRITE_MASK)
> +
> +#define INIT_LDTR_ATTRIBS (SVM_SELECTOR_P_MASK | 2)
> +#define INIT_TR_ATTRIBS (SVM_SELECTOR_P_MASK | 3)
> +
> +static void *snp_safe_alloc_page(void)
safe?
And you don't need to say "safe" - snp_alloc_vmsa_page() is perfectly fine.
> +{
> + unsigned long pfn;
> + struct page *p;
> +
> + /*
> + * Allocate an SNP safe page to workaround the SNP erratum where
> + * the CPU will incorrectly signal an RMP violation #PF if a
> + * hugepage (2mb or 1gb) collides with the RMP entry of VMSA page.
2MB or 1GB
Collides how? The 4K frame is inside the hugepage?
> + * The recommeded workaround is to not use the large page.
Unknown word [recommeded] in comment, suggestions:
['recommended', 'recommend', 'recommitted', 'commended', 'commandeered']
> + *
> + * Allocate one extra page, use a page which is not 2mb aligned
2MB-aligned
> + * and free the other.
> + */
> + p = alloc_pages(GFP_KERNEL_ACCOUNT | __GFP_ZERO, 1);
> + if (!p)
> + return NULL;
> +
> + split_page(p, 1);
> +
> + pfn = page_to_pfn(p);
> + if (IS_ALIGNED(__pfn_to_phys(pfn), PMD_SIZE)) {
> + pfn++;
> + __free_page(p);
> + } else {
> + __free_page(pfn_to_page(pfn + 1));
> + }
AFAICT, this is doing all this stuff so that you can make sure you get a
non-2M-aligned page. I wonder if there's a way to simply ask mm to give
you such page directly.
vbabka?
> +
> + return page_address(pfn_to_page(pfn));
> +}
> +
> +static int wakeup_cpu_via_vmgexit(int apic_id, unsigned long start_ip)
> +{
> + struct sev_es_save_area *cur_vmsa, *vmsa;
> + struct ghcb_state state;
> + unsigned long flags;
> + struct ghcb *ghcb;
> + int cpu, err, ret;
> + u8 sipi_vector;
> + u64 cr4;
> +
> + if ((sev_hv_features & GHCB_HV_FT_SNP_AP_CREATION) != GHCB_HV_FT_SNP_AP_CREATION)
> + return -EOPNOTSUPP;
> +
> + /*
> + * Verify the desired start IP against the known trampoline start IP
> + * to catch any future new trampolines that may be introduced that
> + * would require a new protected guest entry point.
> + */
> + if (WARN_ONCE(start_ip != real_mode_header->trampoline_start,
> + "Unsupported SEV-SNP start_ip: %lx\n", start_ip))
> + return -EINVAL;
> +
> + /* Override start_ip with known protected guest start IP */
> + start_ip = real_mode_header->sev_es_trampoline_start;
> +
> + /* Find the logical CPU for the APIC ID */
> + for_each_present_cpu(cpu) {
> + if (arch_match_cpu_phys_id(cpu, apic_id))
> + break;
> + }
> + if (cpu >= nr_cpu_ids)
> + return -EINVAL;
> +
> + cur_vmsa = per_cpu(snp_vmsa, cpu);
> +
> + /*
> + * A new VMSA is created each time because there is no guarantee that
> + * the current VMSA is the kernels or that the vCPU is not running. If
kernel's.
And if it is not the kernel's, whose it is?
> + * an attempt was done to use the current VMSA with a running vCPU, a
> + * #VMEXIT of that vCPU would wipe out all of the settings being done
> + * here.
I don't understand - this is waking up a CPU, how can it ever be a
running vCPU which is using the current VMSA?!
There is per_cpu(snp_vmsa, cpu), who else can be using that one currently?
> + */
> + vmsa = (struct sev_es_save_area *)snp_safe_alloc_page();
> + if (!vmsa)
> + return -ENOMEM;
> +
> + /* CR4 should maintain the MCE value */
> + cr4 = native_read_cr4() & X86_CR4_MCE;
> +
> + /* Set the CS value based on the start_ip converted to a SIPI vector */
> + sipi_vector = (start_ip >> 12);
> + vmsa->cs.base = sipi_vector << 12;
> + vmsa->cs.limit = 0xffff;
> + vmsa->cs.attrib = INIT_CS_ATTRIBS;
> + vmsa->cs.selector = sipi_vector << 8;
> +
> + /* Set the RIP value based on start_ip */
> + vmsa->rip = start_ip & 0xfff;
> +
> + /* Set VMSA entries to the INIT values as documented in the APM */
> + vmsa->ds.limit = 0xffff;
> + vmsa->ds.attrib = INIT_DS_ATTRIBS;
> + vmsa->es = vmsa->ds;
> + vmsa->fs = vmsa->ds;
> + vmsa->gs = vmsa->ds;
> + vmsa->ss = vmsa->ds;
> +
> + vmsa->gdtr.limit = 0xffff;
> + vmsa->ldtr.limit = 0xffff;
> + vmsa->ldtr.attrib = INIT_LDTR_ATTRIBS;
> + vmsa->idtr.limit = 0xffff;
> + vmsa->tr.limit = 0xffff;
> + vmsa->tr.attrib = INIT_TR_ATTRIBS;
> +
> + vmsa->efer = 0x1000; /* Must set SVME bit */
verify_comment_style: Warning: No tail comments please:
arch/x86/kernel/sev.c:954 [+ vmsa->efer = 0x1000; /* Must set SVME bit */]
> + vmsa->cr4 = cr4;
> + vmsa->cr0 = 0x60000010;
> + vmsa->dr7 = 0x400;
> + vmsa->dr6 = 0xffff0ff0;
> + vmsa->rflags = 0x2;
> + vmsa->g_pat = 0x0007040600070406ULL;
> + vmsa->xcr0 = 0x1;
> + vmsa->mxcsr = 0x1f80;
> + vmsa->x87_ftw = 0x5555;
> + vmsa->x87_fcw = 0x0040;
Yah, those definitely need macros or at least comments ontop denoting
what those naked values are.
> +
> + /*
> + * Set the SNP-specific fields for this VMSA:
> + * VMPL level
> + * SEV_FEATURES (matches the SEV STATUS MSR right shifted 2 bits)
> + */
Like this^^
> + vmsa->vmpl = 0;
> + vmsa->sev_features = sev_status >> 2;
> +
> + /* Switch the page over to a VMSA page now that it is initialized */
> + ret = snp_set_vmsa(vmsa, true);
> + if (ret) {
> + pr_err("set VMSA page failed (%u)\n", ret);
> + free_page((unsigned long)vmsa);
> +
> + return -EINVAL;
> + }
> +
> + /* Issue VMGEXIT AP Creation NAE event */
> + local_irq_save(flags);
> +
> + ghcb = __sev_get_ghcb(&state);
> +
> + vc_ghcb_invalidate(ghcb);
> + ghcb_set_rax(ghcb, vmsa->sev_features);
> + ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_AP_CREATION);
> + ghcb_set_sw_exit_info_1(ghcb, ((u64)apic_id << 32) | SVM_VMGEXIT_AP_CREATE);
> + ghcb_set_sw_exit_info_2(ghcb, __pa(vmsa));
> +
> + sev_es_wr_ghcb_msr(__pa(ghcb));
> + VMGEXIT();
> +
> + if (!ghcb_sw_exit_info_1_is_valid(ghcb) ||
> + lower_32_bits(ghcb->save.sw_exit_info_1)) {
> + pr_alert("SNP AP Creation error\n");
alert?
> + ret = -EINVAL;
> + }
> +
> + __sev_put_ghcb(&state);
> +
> + local_irq_restore(flags);
> +
> + /* Perform cleanup if there was an error */
> + if (ret) {
> + err = snp_set_vmsa(vmsa, false);
> + if (err)
> + pr_err("clear VMSA page failed (%u), leaking page\n", err);
> + else
> + free_page((unsigned long)vmsa);
That...
> +
> + vmsa = NULL;
> + }
> +
> + /* Free up any previous VMSA page */
> + if (cur_vmsa) {
> + err = snp_set_vmsa(cur_vmsa, false);
> + if (err)
> + pr_err("clear VMSA page failed (%u), leaking page\n", err);
> + else
> + free_page((unsigned long)cur_vmsa);
.. and that wants to be in a common helper.
> + }
> +
> + /* Record the current VMSA page */
> + per_cpu(snp_vmsa, cpu) = vmsa;
> +
> + return ret;
> +}
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-12-31 15:36 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 15:42 [PATCH v8 00/40] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-12-10 15:42 ` [PATCH v8 01/40] x86/compressed/64: detect/setup SEV/SME features earlier in boot Brijesh Singh
2021-12-10 18:47 ` Dave Hansen
2021-12-10 19:12 ` Borislav Petkov
2021-12-10 19:23 ` Dave Hansen
2021-12-10 19:33 ` Borislav Petkov
2021-12-13 19:09 ` Venu Busireddy
2021-12-13 19:17 ` Borislav Petkov
2021-12-14 17:46 ` Venu Busireddy
2021-12-14 19:10 ` Borislav Petkov
2021-12-15 0:14 ` Venu Busireddy
2021-12-15 11:57 ` Borislav Petkov
2021-12-15 14:43 ` Tom Lendacky
2021-12-15 17:49 ` Michael Roth
2021-12-15 18:17 ` Venu Busireddy
2021-12-15 18:33 ` Borislav Petkov
2021-12-15 20:17 ` Michael Roth
2021-12-15 20:38 ` Borislav Petkov
2021-12-15 21:22 ` Michael Roth
2022-01-03 19:10 ` Venu Busireddy
2022-01-05 19:34 ` Brijesh Singh
2022-01-10 20:46 ` Brijesh Singh
2022-01-10 21:17 ` Venu Busireddy
2022-01-10 21:38 ` Borislav Petkov
2021-12-15 20:43 ` Michael Roth
2021-12-15 19:54 ` Venu Busireddy
2021-12-15 18:58 ` Venu Busireddy
2021-12-15 17:51 ` Michael Roth
2021-12-10 15:42 ` [PATCH v8 02/40] x86/sev: " Brijesh Singh
2021-12-13 22:36 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 03/40] x86/mm: Extend cc_attr to include AMD SEV-SNP Brijesh Singh
2021-12-13 22:47 ` Venu Busireddy
2021-12-14 15:53 ` Borislav Petkov
2021-12-10 15:42 ` [PATCH v8 04/40] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-12-14 0:13 ` Venu Busireddy
2021-12-14 22:22 ` Borislav Petkov
2021-12-10 15:42 ` [PATCH v8 05/40] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-12-14 0:32 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 06/40] x86/sev: Check SEV-SNP features support Brijesh Singh
2021-12-16 15:47 ` Borislav Petkov
2021-12-16 16:28 ` Brijesh Singh
2021-12-16 16:58 ` Borislav Petkov
2021-12-16 19:01 ` Venu Busireddy
2021-12-10 15:42 ` [PATCH v8 07/40] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-12-16 20:20 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 08/40] x86/sev: Check the vmpl level Brijesh Singh
2021-12-16 20:24 ` Venu Busireddy
2021-12-16 23:39 ` Mikolaj Lisik
2021-12-17 22:19 ` Brijesh Singh
2021-12-17 22:33 ` Tom Lendacky
2021-12-20 18:10 ` Borislav Petkov
2022-01-04 15:23 ` Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 09/40] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-12-17 20:47 ` Venu Busireddy
2021-12-17 23:24 ` Brijesh Singh
2022-01-03 18:43 ` Venu Busireddy
2021-12-21 13:01 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 10/40] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2022-01-03 19:54 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 11/40] x86/sev: " Brijesh Singh
2021-12-22 13:16 ` Borislav Petkov
2021-12-22 15:16 ` Brijesh Singh
2022-01-03 22:47 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 12/40] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-12-23 11:50 ` Borislav Petkov
2022-01-04 15:33 ` Brijesh Singh
2022-01-03 23:28 ` Venu Busireddy
2022-01-11 21:22 ` Brijesh Singh
2022-01-11 21:51 ` Venu Busireddy
2022-01-11 21:57 ` Brijesh Singh
2022-01-11 22:42 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 13/40] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-12-28 11:53 ` Borislav Petkov
2022-01-04 17:56 ` Venu Busireddy
2022-01-05 19:52 ` Brijesh Singh
2022-01-05 20:27 ` Dave Hansen
2022-01-05 21:39 ` Brijesh Singh
2022-01-06 17:40 ` Venu Busireddy
2022-01-06 19:06 ` Tom Lendacky
2022-01-06 20:16 ` Venu Busireddy
2022-01-06 20:50 ` Tom Lendacky
2021-12-10 15:43 ` [PATCH v8 14/40] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-12-28 15:40 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 15/40] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-12-29 11:09 ` Borislav Petkov
2022-01-04 22:31 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 16/40] KVM: SVM: Define sev_features and vmpl field in the VMSA Brijesh Singh
2022-01-04 22:59 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 17/40] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-12-30 12:19 ` Borislav Petkov
2022-01-05 1:38 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 18/40] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2022-01-05 18:41 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 19/40] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2022-01-05 18:54 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 20/40] x86/sev: Use SEV-SNP AP creation to start secondary CPUs Brijesh Singh
2021-12-10 18:50 ` Dave Hansen
2022-01-12 16:17 ` Brijesh Singh
2021-12-31 15:36 ` Borislav Petkov [this message]
2022-01-03 18:10 ` Vlastimil Babka
2022-01-12 16:33 ` Brijesh Singh
2022-01-12 17:10 ` Tom Lendacky
2022-01-13 12:23 ` Borislav Petkov
2022-01-13 12:21 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 21/40] x86/head: re-enable stack protection for 32/64-bit builds Brijesh Singh
2022-01-03 16:49 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 22/40] x86/sev: move MSR-based VMGEXITs for CPUID to helper Brijesh Singh
2021-12-30 18:52 ` Sean Christopherson
2022-01-04 20:57 ` Borislav Petkov
2022-01-04 23:36 ` Michael Roth
2022-01-06 18:38 ` Venu Busireddy
2022-01-06 20:21 ` Michael Roth
2022-01-06 20:36 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 23/40] KVM: x86: move lookup of indexed CPUID leafs " Brijesh Singh
2022-01-06 18:46 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 24/40] x86/compressed/acpi: move EFI system table lookup " Brijesh Singh
2021-12-10 18:54 ` Dave Hansen
2021-12-13 15:47 ` Michael Roth
2021-12-13 16:21 ` Dave Hansen
2021-12-13 18:00 ` Michael Roth
2022-01-11 8:59 ` Chao Fan
2022-01-05 23:50 ` Borislav Petkov
2022-01-06 19:59 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 25/40] x86/compressed/acpi: move EFI config " Brijesh Singh
2022-01-06 20:33 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 26/40] x86/compressed/acpi: move EFI vendor " Brijesh Singh
2022-01-06 20:47 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 27/40] x86/boot: Add Confidential Computing type to setup_data Brijesh Singh
2021-12-10 19:12 ` Dave Hansen
2021-12-10 20:18 ` Brijesh Singh
2021-12-10 20:30 ` Dave Hansen
2021-12-13 14:49 ` Brijesh Singh
2021-12-13 15:08 ` Dave Hansen
2021-12-13 15:55 ` Brijesh Singh
2022-01-07 11:54 ` Borislav Petkov
2022-01-06 22:48 ` Venu Busireddy
2021-12-10 15:43 ` [PATCH v8 28/40] KVM: SEV: Add documentation for SEV-SNP CPUID Enforcement Brijesh Singh
2022-01-07 13:22 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 29/40] x86/compressed/64: add support for SEV-SNP CPUID table in #VC handlers Brijesh Singh
2022-01-13 13:16 ` Borislav Petkov
2022-01-13 16:39 ` Michael Roth
2022-01-14 16:13 ` Borislav Petkov
2022-01-18 4:35 ` Michael Roth
2022-01-18 14:02 ` Borislav Petkov
2022-01-18 14:23 ` Michael Roth
2022-01-18 14:32 ` Michael Roth
2022-01-18 14:37 ` Michael Roth
2022-01-18 16:34 ` Borislav Petkov
2022-01-18 17:20 ` Michael Roth
2022-01-18 17:41 ` Borislav Petkov
2022-01-18 18:49 ` Michael Roth
2022-01-19 1:18 ` Michael Roth
2022-01-19 11:17 ` Borislav Petkov
2022-01-19 16:27 ` Michael Roth
2022-01-27 17:23 ` Michael Roth
2022-01-28 22:58 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 30/40] x86/boot: add a pointer to Confidential Computing blob in bootparams Brijesh Singh
2022-01-17 18:14 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 31/40] x86/compressed: add SEV-SNP feature detection/setup Brijesh Singh
2022-01-19 12:55 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 32/40] x86/compressed: use firmware-validated CPUID for SEV-SNP guests Brijesh Singh
2022-01-20 12:18 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 33/40] x86/compressed/64: add identity mapping for Confidential Computing blob Brijesh Singh
2021-12-10 19:52 ` Dave Hansen
2021-12-13 17:54 ` Michael Roth
2022-01-25 13:48 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 34/40] x86/sev: add SEV-SNP feature detection/setup Brijesh Singh
2022-01-25 18:43 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 35/40] x86/sev: use firmware-validated CPUID for SEV-SNP guests Brijesh Singh
2022-01-26 18:35 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 36/40] x86/sev: Provide support for SNP guest request NAEs Brijesh Singh
2022-01-27 16:21 ` Borislav Petkov
2022-01-27 17:02 ` Brijesh Singh
2022-01-29 10:27 ` Borislav Petkov
2022-01-29 11:49 ` Brijesh Singh
2022-01-29 12:02 ` Borislav Petkov
2021-12-10 15:43 ` [PATCH v8 37/40] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 38/40] virt: Add SEV-SNP guest driver Brijesh Singh
2021-12-10 15:43 ` [PATCH v8 39/40] virt: sevguest: Add support to derive key Brijesh Singh
2021-12-10 22:27 ` Liam Merwick
2021-12-10 15:43 ` [PATCH v8 40/40] virt: sevguest: Add support to get extended report Brijesh Singh
2021-12-10 20:17 ` [PATCH v8 00/40] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Dave Hansen
2021-12-10 20:20 ` Brijesh Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yc8jerEP5CrxfFi4@zn.tnic \
--to=bp@alien8.de \
--cc=ak@linux.intel.com \
--cc=ardb@kernel.org \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=dgilbert@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jroedel@suse.de \
--cc=kirill@shutemov.name \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=marcorr@google.com \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rientjes@google.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=slp@redhat.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tobin@ibm.com \
--cc=tony.luck@intel.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).