search for: stune

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

On 4/24/20 2:03 PM, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. > > --- > SEV-ES guests will need to execute rdtsc and rdtscp from userspace and > during early boot. Move the rdtsc(p) #VC handler into common code an...

On 4/24/20 2:03 PM, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. > > --- > SEV-ES guests will need to execute rdtsc and rdtscp from userspace and > during early boot. Move the rdtsc(p) #VC handler into common code an...

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

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

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

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() f...

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 arch/x86/mm/pat/set_memory.c. > > > > I agree that the return code needs to be checked. But I...

On 4/24/20 4:24 PM, Dave Hansen wrote: > On 4/24/20 2:03 PM, Mike Stunes wrote: >> I needed to allow RDTSC(P) from userspace and in early boot in order to >> get userspace started properly. Patch below. >> >> --- >> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and >> during early boot. Move the rdtsc(p) #VC hand...

Hi Mike, On Fri, Apr 24, 2020 at 02:03:16PM -0700, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. Thanks, but this is not needed anymore. I removed the vc_context_filter from the code. The emulation code is now capable of safely handling any exception from user...

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

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/arc...

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

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

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

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

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

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

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

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