similar to: [PATCH v6 00/76] x86: SEV-ES Guest Support

Hi Mike, On Thu, Aug 20, 2020 at 12:58:13AM +0000, Mike Stunes wrote: > Yes, I still see the issue ? APs are offline after boot. I?ll spend > some time seeing if I can figure out what the problem is. Thanks! Tom and a few others debugged another FSGSBASE issue yesterday, which I think might also be the cause for the AP startup problems you are seeing (if you test on Rome). Can you try to

On Mon, Aug 24, 2020 at 10:54:33AM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > Early exception handling will use rd/wrgsbase in paranoid_entry/exit. > Enable the feature to avoid #UD exceptions on boot APs. > > Signed-off-by: Joerg Roedel <jroedel at suse.de> > Link: https://lore.kernel.org/r/20200724160336.5435-38-joro at 8bytes.org

On Mon, Aug 24, 2020 at 10:54:33AM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > Early exception handling will use rd/wrgsbase in paranoid_entry/exit. > Enable the feature to avoid #UD exceptions on boot APs. > > Signed-off-by: Joerg Roedel <jroedel at suse.de> > Link: https://lore.kernel.org/r/20200724160336.5435-38-joro at 8bytes.org

On Sat, Aug 29, 2020 at 05:55:25PM +0200, Borislav Petkov wrote: > On Mon, Aug 24, 2020 at 10:54:33AM +0200, Joerg Roedel wrote: > > From: Joerg Roedel <jroedel at suse.de> > > > > Early exception handling will use rd/wrgsbase in paranoid_entry/exit. > > Enable the feature to avoid #UD exceptions on boot APs. > > > > Signed-off-by: Joerg Roedel

Hi Mike, On Thu, Aug 20, 2020 at 12:58:13AM +0000, Mike Stunes wrote: > Yes, I still see the issue ? APs are offline after boot. I?ll spend > some time seeing if I can figure out what the problem is. Thanks! Thanks. I think the first step here would be to find out where on the APs (which RIP) the first #VC exception happens. I guess in the #VC entry code it triggers the next exception when

From: Joerg Roedel <jroedel at suse.de> Early exception handling will use rd/wrgsbase in paranoid_entry/exit. Enable the feature to avoid #UD exceptions on boot APs. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-38-joro at 8bytes.org --- arch/x86/kernel/head_64.S | 7 +++++++ 1 file changed, 7 insertions(+) diff --git

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

Hi Mike, On Thu, Jul 30, 2020 at 11:23:50PM +0000, Mike Stunes wrote: > Yes, FSGSBASE was enabled. If I disable it*, this kernel boots fine, with > both CPUs online. > > *That is, by forcing guest-CPUID[7].EBX bit 0 to 0. Can you please test whether https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=sev-es-client-tip-5.9 still triggers this issue on your side?

Hi Mike, On Thu, Jul 30, 2020 at 01:27:48AM +0000, Mike Stunes wrote: > Thanks for the updated patches! I applied this patch-set onto commit > 01634f2bd42e ("Merge branch 'x86/urgent??) from your tree. It boots, > but CPU 1 (on a two-CPU VM) is offline at boot, and `chcpu -e 1` returns: > > chcpu: CPU 1 enable failed: Input/output error > > with nothing in dmesg to

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

From: Joerg Roedel <jroedel at suse.de> Add the sev_es_active function for checking whether SEV-ES is enabled. Also cache the value of MSR_AMD64_SEV at boot to speed up the feature checking in the running code. Signed-off-by: Joerg Roedel <jroedel at suse.de> Reviewed-by: Kees Cook <keescook at chromium.org> Link: https://lore.kernel.org/r/20200724160336.5435-39-joro at

On Thu, Aug 27, 2020 at 06:48:10PM -0400, Arvind Sankar wrote: > On Mon, Aug 24, 2020 at 10:54:22AM +0200, Joerg Roedel wrote: > > From: Tom Lendacky <thomas.lendacky at amd.com> > > > > Handle #VC exceptions caused by CPUID instructions. These happen in > > early boot code when the KASLR code checks for RDTSC. > > > > Signed-off-by: Tom Lendacky

From: Joerg Roedel <jroedel at suse.de> Handle #VC exceptions caused by #DB exceptions in the guest. Those must be handled outside of instrumentation_begin()/end() so that the handler will not be raised recursivly. Handle them by calling the kernels debug exception handler. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-64-joro

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> >>

From: Joerg Roedel <jroedel at suse.de> Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the vCPU when it reaches IRET. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/entry/entry_64.S | 48 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/sev-es.h | 27 +++++++++++++++++++ arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/nmi.c

From: Joerg Roedel <jroedel at suse.de> Setup an early handler for #VC exceptions. There is no GHCB mapped yet, so just re-use the vc_no_ghcb_handler. It can only handle CPUID exit-codes, but that should be enough to get the kernel through verify_cpu() and __startup_64() until it runs on virtual addresses. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link:

From: Tom Lendacky <thomas.lendacky at amd.com> Add handler for VC exceptions caused by MMIO intercepts. These intercepts come along as nested page faults on pages with reserved bits set. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> [ jroedel at suse.de: Adapt to VC handling framework ] Co-developed-by: Joerg Roedel <jroedel at suse.de> Signed-off-by: Joerg Roedel