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

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

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

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 Fri, Aug 21, 2020 at 05:42:16PM +0000, Mike Stunes wrote: > Yes, that fixes the problem ? I can see both CPUs running now. Thanks! Thanks a lot for testing, good to have this issue resolved. Regards, Joerg

On Sat, Apr 25, 2020 at 3:10 PM Andy Lutomirski <luto at kernel.org> wrote: > > On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > > I assume the race you mean is: > > > > > > #VC > > > Immediate NMI before IST gets shifted > >

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

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

Hi Mike, On Wed, Jul 22, 2020 at 10:53:02PM +0000, Mike Stunes wrote: > Thanks Joerg! With that change in place, this kernel boots normally. > What was the problem? The problem was that the code got its page-table from current->active_mm. But these pointers are not set up during early boot, so that the #VC handler can't walk the page-table and propagates a page-fault every time.

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 arch/x86/mm/pat/set_memory.c. I agree that the return code needs to be checked. But I wonder why this happens. The split_large_page() function returns -ENOMEM when

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

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>

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