similar to: [PATCH 40/70] x86/sev-es: Setup per-cpu GHCBs for the runtime handler

On Wed, Apr 22, 2020 at 06:33:13PM -0700, Bo Gan wrote: > On 4/15/20 8:53 AM, Joerg Roedel wrote: > > Hi Mike, > > > > On Tue, Apr 14, 2020 at 07:03:44PM +0000, Mike Stunes wrote: > > > set_memory_decrypted needs to check the return value. I see it > > > consistently return ENOMEM. I've traced that back to split_large_page > > > in

On 4/14/20 2:03 PM, Mike Stunes wrote: > On Mar 19, 2020, at 2:13 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Tom Lendacky <thomas.lendacky at amd.com> >> >> The runtime handler needs a GHCB per CPU. Set them up and map them >> unencrypted. >> >> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> >>

On 4/14/20 2:03 PM, Mike Stunes wrote: > On Mar 19, 2020, at 2:13 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Tom Lendacky <thomas.lendacky at amd.com> >> >> The runtime handler needs a GHCB per CPU. Set them up and map them >> unencrypted. >> >> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> >>

On 4/14/20 3:12 PM, Dave Hansen wrote: > On 4/14/20 1:04 PM, Tom Lendacky wrote: >>> set_memory_decrypted needs to check the return value. I see it >>> consistently return ENOMEM. I've traced that back to split_large_page >>> in arch/x86/mm/pat/set_memory.c. >> >> At that point the guest won't be able to communicate with the >> hypervisor,

On 4/14/20 1:04 PM, Tom Lendacky wrote: >> set_memory_decrypted needs to check the return value. I see it >> consistently return ENOMEM. I've traced that back to split_large_page >> in arch/x86/mm/pat/set_memory.c. > > At that point the guest won't be able to communicate with the > hypervisor, too. Maybe we should BUG() here to terminate further > processing?

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 25 ++++++++++++++++++++++++- arch/x86/kernel/traps.c

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Tom Lendacky <thomas.lendacky at amd.com> > > The runtime handler needs a GHCB per CPU. Set them up and map them > unencrypted. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > Signed-off-by: Joerg Roedel <jroedel at suse.de> > --- >

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 56 +++++++++++++++++++++++++++++- arch/x86/kernel/traps.c

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 56 +++++++++++++++++++++++++++++- arch/x86/kernel/traps.c

On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c > index a4fa7f351bf2..bc3a58427028 100644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -10,6 +10,7 @@ > #include <linux/sched/debug.h> /* For show_regs() */ > #include <linux/percpu-defs.h> > #include

On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c > index a4fa7f351bf2..bc3a58427028 100644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -10,6 +10,7 @@ > #include <linux/sched/debug.h> /* For show_regs() */ > #include <linux/percpu-defs.h> > #include

From: Tom Lendacky <thomas.lendacky at amd.com> Add the handler for #VC exceptions invoked at runtime. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/entry/entry_64.S | 4 + arch/x86/include/asm/traps.h | 7 ++ arch/x86/kernel/idt.c | 4 +- arch/x86/kernel/sev-es.c | 167

On 5/6/20 1:08 PM, Mike Stunes wrote: > > >> On Apr 28, 2020, at 8:17 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Mike Stunes <mstunes at vmware.com> >> >> To avoid a future VMEXIT for a subsequent CPUID function, cache the >> results returned by CPUID into an xarray. >> >> [tl: coding standard changes, register zero

From: Mike Stunes <mstunes at vmware.com> To avoid a future VMEXIT for a subsequent CPUID function, cache the results returned by CPUID into an xarray. [tl: coding standard changes, register zero extension] Signed-off-by: Mike Stunes <mstunes at vmware.com> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> [ jroedel at suse.de: - Wrapped cache handling into

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom

On Sat, May 23, 2020 at 09:59:24AM +0200, Borislav Petkov wrote: > On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > > + /* > > + * Mark the per-cpu GHCBs as in-use to detect nested #VC exceptions. > > + * There is no need for it to be atomic, because nothing is written to > > + * the GHCB between the read and the write of ghcb_active. So it is safe >

On Thu, Jun 11, 2020 at 01:48:31PM +0200, Joerg Roedel wrote: > On Sat, May 23, 2020 at 09:59:24AM +0200, Borislav Petkov wrote: > > On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > > > + /* > > > + * Mark the per-cpu GHCBs as in-use to detect nested #VC exceptions. > > > + * There is no need for it to be atomic, because nothing is written to

Hmm, I have a theory ... On Tue, Jul 21, 2020 at 09:01:44PM +0000, Mike Stunes wrote: > If I remove the call to probe_roms from setup_arch, or remove the calls to romchecksum from probe_roms, this kernel boots normally. > > Please let me know of other tests I should run or data that I can collect. Thanks! ... can you please try the attached diff? diff --git a/arch/x86/kernel/sev-es.c

Hi Mike, On Tue, Jul 21, 2020 at 09:01:44PM +0000, Mike Stunes wrote: > I?m running into an MMIO-related bug when I try testing this on our hypervisor. > > During boot, probe_roms (arch/x86/kernel/probe_roms.c) uses > romchecksum over the video ROM and extension ROM regions. In my test > VM, the video ROM romchecksum starts at virtual address > 0xffff8880000c0000 and has length