similar to: [PATCH] hide RDTSCP feature flag from PV guests

(Applies cleanly only on top of the previously sent SVM/LBR patch.) Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/hvm/svm/svm.c =================================================================== --- 2007-08-08.orig/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:40:11.000000000 +0200 +++ 2007-08-08/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:43:53.000000000 +0200

- use __clear_bit() rather than clear_bit() - use switch statements instead of long series of if-s - eliminate pointless casts (Applies cleanly only on top of the previously sent SVM/EFER patch.) Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/hvm/hvm.c =================================================================== ---

qemu recently added support for 3dnow instructions. Because of that, 3dnow will be featured among cpuid bits. But this will break kvm in cpus that don't have those instructions (which includes my laptop). So we fixup our cpuid before exposing it to the guest. Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kvm/x86.c | 22 ++++++++++++++++++----

qemu recently added support for 3dnow instructions. Because of that, 3dnow will be featured among cpuid bits. But this will break kvm in cpus that don't have those instructions (which includes my laptop). So we fixup our cpuid before exposing it to the guest. Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kvm/x86.c | 22 ++++++++++++++++++----

.. for both 32-bit apps in 64-bit pv guests and 32on64. This patch depends on more than just guest_context saved/restored as guest state during save/restore/migrate (namely the new fields holding callback addresses). Since the 32-bit kernel doesn''t make use of syscall (it would be possible to do so now, when running on a 64-bit hv), the compat mode guest code path for syscall

# HG changeset patch # User Paul Durrant <paul.durrant@citrix.com> # Date 1309796247 -3600 # Node ID 6ce0dbc6f955707bf814d62a16a2b4382d957332 # Parent 7e4404a8f5f9bc111a80f15a2bce35378b39f2f1 Don''t expose CPUID time leaf when not using PVRDTSCP Some versions of Oracle''s Solaris PV drivers make a check that the maximal Xen hypervisor CPUID leaf is <= base leaf + 2 and

>>However, in case (2) the i386 guest kernel unconditionally goes for >>sysenter, and the hypervisor will accept this because CPUID has advertised >>SEP. *But* AMD CPUs do not support sysenter except in legacy mode! The >>correct thing to do is to use syscall. The hypervisor 32-on-64 compat code >>would accept CALLBACKTYPE_syscall, but the Linux i386 code here

From: Borislav Petkov <bp at suse.de> Using static_cpu_has() is pointless on those paths, convert them to the boot_cpu_has() variant. No functional changes. Reported-by: Nadav Amit <nadav.amit at gmail.com> Signed-off-by: Borislav Petkov <bp at suse.de> Cc: Aubrey Li <aubrey.li at intel.com> Cc: Dave Hansen <dave.hansen at intel.com> Cc: Dominik Brodowski <linux

plain text document attachment (xx-paravirt-vsyscall.patch) vsyscall interface updates for paravirt ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/vsyscall.c =================================================================== --- clean-start.orig/arch/x86_64/kernel/vsyscall.c +++

plain text document attachment (xx-paravirt-vsyscall.patch) vsyscall interface updates for paravirt ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/vsyscall.c =================================================================== --- clean-start.orig/arch/x86_64/kernel/vsyscall.c +++

Hi Erwan, First off, many thanks for your wonderful addition to syslinux: dmitest.c32 and another thankyou to hpa for it's inclusion. I need to ask if you are missing a couple of definitions in dmi_processor.h, specifically, the "long mode" flag. I need to use this flag to determine whether a machine is 64-bit capable or not. There is a great web page explaining the "long

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 handler into common code and

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-space. Regards, Joerg

Hi Dave, On Fri, Apr 24, 2020 at 03:53:09PM -0700, Dave Hansen wrote: > Ahh, so any instruction that can have an instruction intercept set > potentially needs to be able to tolerate a #VC? Those instruction > intercepts are under the control of the (untrusted relative to the > guest) hypervisor, right? > > >From the main sev-es series: > > +#ifdef

On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: > shift_ist is gross. What's it for? If it's not needed, I'd rather > not use it, and I eventually want to get rid of it for #DB as well. The #VC handler needs to be able to nest, there is no way around that for various reasons, the two most important ones are: 1. The #VC -> NMI -> #VC case. #VCs can

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 > #VC > > Kaboom. > > How are you dealing with this? Ultimately, I think that NMI will need > to turn off IST before engaging in any funny business. Let me ponder > this a bit. Right, I dealt with that by

On Tue, Apr 28, 2020 at 09:55:12AM +0200, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > > I have a somewhat serious question: should we use IST for #VC at all? > > As I understand it, Rome and Naples make it mandatory for hypervisors > > to intercept #DB, which means that, due to the MOV SS mess, it's sort > > of mandatory

On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > Hi Peter, > > On Tue, Jun 23, 2020 at 12:45:59PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > > Or maybe you have a better idea how to implement this, so I'd like to > > > hear your opinion first before I spend too many days implementing >

On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > Note that this is an issue only with secure nested paging (SNP), which > is not enabled yet with this patch-set. When it gets enabled a stack > recursion check in the #VC handler is needed which panics the VM. That > also fixes the #VC-in-early-NMI problem. But you cannot do a recursion check in #VC, because the NMI can

On Tue, Jun 23, 2020 at 01:43:24PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:14:43PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > > > > The v3 patchset implements an unconditional shift of the #VC IST entry > > > in the NMI handler, before it can trigger a #VC exception. > > > > Going by