similar to: [PATCH v5 00/75] x86: SEV-ES Guest Support

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

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

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

From: Joerg Roedel <jroedel at suse.de> Refactor the message printed to the kernel log which indicates whether SEV or SME is active to print a list of enabled encryption features. This will scale better in the future when more memory encryption features might be added. Also add SEV-ES to the list of features. Signed-off-by: Joerg Roedel <jroedel at suse.de> ---

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> --- arch/x86/include/asm/mem_encrypt.h | 3 +++ arch/x86/include/asm/msr-index.h | 2 ++ arch/x86/mm/mem_encrypt.c

From: Martin Radev <martin.b.radev at gmail.com> Make sure the machine supports RDRAND, otherwise there is no trusted source of of randomness in the system. To also check this in the pre-decompression stage, make has_cpuflag not depend on CONFIG_RANDOMIZE_BASE anymore. Signed-off-by: Martin Radev <martin.b.radev at gmail.com> Signed-off-by: Joerg Roedel <jroedel at suse.de>

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

Hi Mike, On Tue, Aug 25, 2020 at 12:21:03AM +0000, Mike Stunes wrote: > Thanks for the new update! I still see the same FSGSBASE behavior on our platform. > > That is, APs come up offline; masking out either FSGSBASE or RDPID from the > guest's CPUID results in all CPUs online. > > Is that still expected with this patch set? (As you mentioned in an earlier reply, > I?m

On Tue, Apr 28, 2020 at 05:17:01PM +0200, Joerg Roedel wrote: > 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

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 Tue, Apr 28, 2020 at 05:17:09PM +0200, Joerg Roedel wrote: > From: Tom Lendacky <thomas.lendacky at amd.com> > > Implement a handler for #VC exceptions caused by MONITOR and MONITORX > instructions. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: Adapt to #VC handling infrastructure ] > Co-developed-by: Joerg Roedel

On Tue, Apr 28, 2020 at 05:17:09PM +0200, Joerg Roedel wrote: > From: Tom Lendacky <thomas.lendacky at amd.com> > > Implement a handler for #VC exceptions caused by MONITOR and MONITORX > instructions. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: Adapt to #VC handling infrastructure ] > Co-developed-by: Joerg Roedel

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> --- arch/x86/include/asm/mem_encrypt.h | 3 +++ arch/x86/include/asm/msr-index.h | 2 ++ arch/x86/mm/mem_encrypt.c

From: Tom Lendacky <thomas.lendacky at amd.com> Implement a handler for #VC exceptions caused by RDMSR/WRMSR instructions. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> [ jroedel at suse.de: Adapt to #VC handling infrastructure ] Co-developed-by: Joerg Roedel <jroedel at suse.de> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/sev-es.c |