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

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

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

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

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

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

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

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

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

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.

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>