Re: [Xen-devel] Xen PV seems to be broken on Linus' tree

On Wed, Nov 22, 2017 at 4:50 AM, Juergen Gross <jgr...@suse.com> wrote: > On 22/11/17 05:46, Andy Lutomirski wrote: >> On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski <l...@

Re: [Xen-devel] Xen PV seems to be broken on Linus' tree

On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski <l...@kernel.org> wrote: >> I'm doing: >> >> /usr/bin/qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -net none >> -nographic -ke

Re: [Xen-devel] Xen PV seems to be broken on Linus' tree

On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski <l...@kernel.org> wrote: > I'm doing: > > /usr/bin/qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -net none > -nographic -kernel xen-4.8.2 -initrd './arch/x86/boot/bzImage' -m 2G > -smp 2 -append console=com1 &

[Xen-devel] Xen PV seems to be broken on Linus' tree

I'm doing: /usr/bin/qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -net none -nographic -kernel xen-4.8.2 -initrd './arch/x86/boot/bzImage' -m 2G -smp 2 -append console=com1 With Linus' commit c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 and the attached config. It dies with a bunch of

Re: [Xen-devel] [PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support

> On Oct 20, 2017, at 5:20 PM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > */ - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp) + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11 + cmpq

Re: [Xen-devel] [PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support

> On Oct 20, 2017, at 5:20 PM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > */ - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp) + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11 + cmpq

[Xen-devel] [PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

range the SYSCALL entries") Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/xen/xen-asm_64.S | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index a8a4f4c460a6..c5fee2680abc 100644 --- a/arch/x86/xen/xen

Re: [Xen-devel] [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Sun, Aug 13, 2017 at 10:53 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst <brge...@gmail.com> wrote: >> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> /* Normal 64-

Re: [Xen-devel] [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst <brge...@gmail.com> wrote: > On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski <l...@kernel.org> wrote: >> /* Normal 64-bit system call target */ >> ENTRY(xen_syscall_target) >> - undo_xen_syscall >> -

[Xen-devel] [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

from similar treatment. This makes one change to the native code path: the compat instruction that clears the high 32 bits of %rax is moved slightly later. I'd be surprised if this affects performance at all. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- Changes from v1 (which I

Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame

On Mon, Aug 7, 2017 at 1:56 PM, Boris Ostrovsky wrote: > >> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >> index 811e4ddb3f37..a3dcd83187ce 100644 >> --- a/arch/x86/xen/enlighten_pv.c >> +++ b/arch/x86/xen/enlighten_pv.c >> @@ -579,6 +579,71

Re: [Xen-devel] [PATCH v2] xen: get rid of paravirt op adjust_exception_frame

On Tue, Aug 1, 2017 at 4:38 PM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 01/08/2017 20:45, Andy Lutomirski wrote: >> Also, IMO it would be nice to fully finish the job. Remaining steps are: >> >> 1. Unsuck the SYSCALL entries on Xen PV. >> 2. Unsuck

Re: [Xen-devel] [PATCH v2] xen: get rid of paravirt op adjust_exception_frame

On Tue, Aug 1, 2017 at 3:39 AM, Juergen Gross wrote: > When running as Xen pv-guest the exception frame on the stack contains > %r11 and %rcx additional to the other data pushed by the processor. > > Instead of having a paravirt op being called for each exception type > prepend

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

> On Jul 26, 2017, at 2:43 PM, Juergen Gross <jgr...@suse.com> wrote: > >> On 26/07/17 19:57, Andy Lutomirski wrote: >> >> >>>> On Jul 26, 2017, at 11:50 AM, Juergen Gross <jgr...@suse.com> wrote: >>>> >>>>> On 2

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

> On Jul 26, 2017, at 11:50 AM, Juergen Gross <jgr...@suse.com> wrote: > >> On 26/07/17 15:48, Andy Lutomirski wrote: >>> On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross <jgr...@suse.com> wrote: >>> When running as Xen pv-guest the exception fra

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On Wed, Jul 26, 2017 at 7:01 AM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 26/07/17 14:48, Andy Lutomirski wrote: >> >>> /* Runs on exception stack */ >>> -ENTRY(nmi) >>> - /* >>> -

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: > When running as Xen pv-guest the exception frame on the stack contains > %r11 and %rcx additional to the other data pushed by the processor. > > Instead of having a paravirt op being called for each exception type > prepend

Re: [Xen-devel] [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME >

Re: [Xen-devel] [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

On Tue, Jun 13, 2017 at 2:26 AM, Borislav Petkov <b...@alien8.de> wrote: > On Mon, Jun 12, 2017 at 10:26:14AM -0700, Andy Lutomirski wrote: >> The kernel has several code paths that read CR3. Most of them assume that >> CR3 contains the PGD's physical address, whereas s

[Xen-devel] [tip:x86/mm] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

Commit-ID: 6c690ee1039b251e583fc65b28da30e97d6a7385 Gitweb: http://git.kernel.org/tip/6c690ee1039b251e583fc65b28da30e97d6a7385 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Mon, 12 Jun 2017 10:26:14 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 13

[Xen-devel] [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

when PCID is enabled. Cc: Tom Lendacky <thomas.lenda...@amd.com> Cc: Juergen Gross <jgr...@suse.com> Cc: xen-devel <xen-devel@lists.xen.org> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- Hi Ingo- I broke thi

[Xen-devel] [PATCH] x86/xen: Improve failed hypercall debugging

When fiddling with xen_exit_mmap(), I noticed that failed multicall debugging doesn't work if the multicall is just one call. Fix it. Cc: Juergen Gross <jgr...@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> S

Re: [Xen-devel] xen_exit_mmap() questions

On Thu, Apr 27, 2017 at 1:00 PM, Boris Ostrovsky <boris.ostrov...@oracle.com> wrote: > On 04/27/2017 12:46 PM, Andy Lutomirski wrote: >> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky >> <boris.ostrov...@oracle.com> wrote: >>>>>>>> Also, t

Re: [Xen-devel] xen_exit_mmap() questions

On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky wrote: > > >> Also, this code in drop_other_mm_ref() looks dubious to me: >> >> /* If this cpu still has a stale cr3 reference, then make sure >>it has been flushed. */ >> if

Re: [Xen-devel] xen_exit_mmap() questions

On Wed, Apr 26, 2017 at 5:55 PM, Boris Ostrovsky <boris.ostrov...@oracle.com> wrote: > > > On 04/26/2017 06:49 PM, Andy Lutomirski wrote: >> >> On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky >> <boris.ostrov...@oracle.com> wrote: >>> >>> O

Re: [Xen-devel] xen_exit_mmap() questions

On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky <boris.ostrov...@oracle.com> wrote: > On 04/26/2017 04:52 PM, Andy Lutomirski wrote: >> I was trying to understand xen_drop_mm_ref() to update it for some >> changes I'm working on, and I'm wondering whether we need >

[Xen-devel] xen_exit_mmap() questions

I was trying to understand xen_drop_mm_ref() to update it for some changes I'm working on, and I'm wondering whether we need xen_exit_mmap() at all. AFAICS the intent is to force all CPUs to drop their lazy uses of the mm being destroyed so it can be unpinned before tearing down the page tables,

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 09/03/2017 21:32, Andy Lutomirski wrote: >> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgar...@google.com> wrote: >> >>> --- a/arch/x86/xen/enlighten.c >>>

Re: [Xen-devel] [PATCH v5 3/3] x86: Make the GDT remapping read-only on 64-bit

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64-bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote: > Each processor holds a GDT in its per-cpu structure. The sgdt > instruction gives the base address of the current GDT. This address can > be used to bypass KASLR memory randomization. With another bug, an > attacker

Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

On Fri, Feb 17, 2017 at 2:01 PM, Thomas Garnier wrote: > On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote: >> On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote: >>> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson

Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote: > The KVM segment_base function is confusing. This patch replaces integers > with appropriate flags, simplify constructs and add comments. It could pay to put this first in the series, but last is probably fine, too. >

Re: [Xen-devel] [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit

On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64 bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction

Re: [Xen-devel] [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit

On Wed, Feb 1, 2017 at 1:15 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This change is done only on 64 bit. > >> >> - table_base = gdt->address; >> +

Re: [Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier wrote: > Each processor holds a GDT in its per-cpu structure. The sgdt > instruction gives the base address of the current GDT. This address can > be used to bypass KASLR memory randomization. With another bug, an > attacker

Re: [Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

fixmap") > > The only user of this interface was kvm. This commit moves > pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it > and adds the correspondent setter routine for it. This allows other > pvclock-based clocksources to use it, such as Xen. With a minor ni

Re: [Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: > This file defines an ABI shared between guest and hypervisor(s) > (KVM, Xen) and as such there should be an correspondent entry in > MAINTAINERS file. Notice that there's already a text notice at the > top of the

Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page

On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: > In order to support pvclock vdso on xen we need to setup the time > info page for vcpu 0 and register the page with Xen using the > VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall > will also

[Xen-devel] [tip:x86/urgent] x86/microcode/intel: Replace sync_core() with native_cpuid()

Commit-ID: 484d0e5c7943644cc46e7308a8f9d83be598f2b9 Gitweb: http://git.kernel.org/tip/484d0e5c7943644cc46e7308a8f9d83be598f2b9 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Fri, 9 Dec 2016 10:24:07 -0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Mon,

[Xen-devel] [tip:x86/urgent] x86/asm: Rewrite sync_core() to use IRET-to-self

Commit-ID: c198b121b1a1d7a7171770c634cd49191bac4477 Gitweb: http://git.kernel.org/tip/c198b121b1a1d7a7171770c634cd49191bac4477 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Fri, 9 Dec 2016 10:24:08 -0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Mon,

[Xen-devel] [tip:x86/urgent] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

Commit-ID: 426d1aff3138cf38da14e912df3c75e312f96e9e Gitweb: http://git.kernel.org/tip/426d1aff3138cf38da14e912df3c75e312f96e9e Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Fri, 9 Dec 2016 10:24:06 -0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Mon,

[Xen-devel] [tip:x86/urgent] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

Commit-ID: 1c52d859cb2d417e7216d3e56bb7fea88444cec9 Gitweb: http://git.kernel.org/tip/1c52d859cb2d417e7216d3e56bb7fea88444cec9 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Fri, 9 Dec 2016 10:24:05 -0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Mon,

Re: [Xen-devel] [PATCH v4 0/4] CPUID-less CPU/sync_core fixes and improvements

On Fri, Dec 9, 2016 at 10:24 AM, Andy Lutomirski <l...@kernel.org> wrote: > *** PATCHES 1 and 2 MAY BE 4.9 MATERIAL *** > > Alan Cox pointed out that the 486 isn't the only supported CPU that > doesn't have CPUID. Let's clean up the mess and make everything > faster while

[Xen-devel] [PATCH v4 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

very slow under KVM, and MOV-to-CR2 is ~42ns. While we're at it: sync_core() serves a very specific purpose. Document it. Cc: "H. Peter Anvin" <h...@zytor.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/include/asm/processor.h | 80 +

[Xen-devel] [PATCH v4 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk> Signed-off-by: Andy Lutomirski <l...@k

[Xen-devel] [PATCH v4 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

t; Cc: Brian Gerst <brge...@gmail.com> Cc: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Th

[Xen-devel] [PATCH v4 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

<b...@alien8.de> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/kernel/cpu/microcode/intel.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c inde

[Xen-devel] [PATCH v4 0/4] CPUID-less CPU/sync_core fixes and improvements

. Changes from v1: - Fix Xen - Add timing info to the changelog (hint: 2x speedup) - Document patch 1 a bit better. Andy Lutomirski (4): x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels Revert "x86/boot: Fail the boot if !M486 and CPUID is missing" x86

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

On Mon, Dec 5, 2016 at 11:52 PM, Borislav Petkov <b...@alien8.de> wrote: > On Mon, Dec 05, 2016 at 01:32:43PM -0800, Andy Lutomirski wrote: >> Aside from being excessively slow, CPUID is problematic: Linux runs >> on a handful of CPUs that don't have CPUID. Use IRET-to-s

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

On Tue, Dec 6, 2016 at 1:49 AM, Jan Beulich wrote: On 06.12.16 at 10:25, wrote: >> On Tue, Dec 06, 2016 at 01:46:37AM -0700, Jan Beulich wrote: >>> > + asm volatile ( >>> > + "pushfl\n\t" >>> > + "pushl %%cs\n\t" >>> > +

[Xen-devel] [PATCH v3 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk> Signed-off-by: Andy Lutomirski <l...@k

[Xen-devel] [PATCH v3 0/4] CPUID-less CPU/sync_core fixes and improvements

speedup) - Document patch 1 a bit better. Andy Lutomirski (4): x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels Revert "x86/boot: Fail the boot if !M486 and CPUID is missing" x86/microcode/intel: Replace sync_core() with native_cpuid() x86/asm: Rewrite

[Xen-devel] [PATCH v3 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

<b...@alien8.de> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/kernel/cpu/microcode/intel.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c inde

[Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

very slow under KVM, and MOV-to-CR2 is ~42ns. While we're at it: sync_core() serves a very specific purpose. Document it. Cc: "H. Peter Anvin" <h...@zytor.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/include/asm/processor.h | 77 +

[Xen-devel] [PATCH v3 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

t; Cc: Brian Gerst <brge...@gmail.com> Cc: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Th

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Dec 2, 2016 10:48 AM, "Boris Ostrovsky" <boris.ostrov...@oracle.com> wrote: > > On 12/02/2016 06:44 AM, Andrew Cooper wrote: > > On 02/12/16 00:35, Andy Lutomirski wrote: > >> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't > >> guara

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 02/12/16 17:07, Andy Lutomirski wrote: >> On Dec 2, 2016 3:44 AM, "Andrew Cooper" <andrew.coop...@citrix.com> wrote: >>> On 02/12/16 00:35, Andy Lutomirski wrote: >>

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Dec 2, 2016 3:44 AM, "Andrew Cooper" <andrew.coop...@citrix.com> wrote: > > On 02/12/16 00:35, Andy Lutomirski wrote: > > On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't > > guaranteed to serialize. (Even CPUID isn't *really* gua

Re: [Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction in newer processors. Bit > 31 of MSR_PLATFORM_INFO advertises support for this feature. It is > documented in detail in Section 2.3.2 of >

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: > arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for > now. Rename the second arg to a more generic name. > > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey <m...@kylehuey.com> wrote: Reviewed-by: Andy Lutomirski <l...@kernel.org> although this is really Borislav's domain. OTOH, if you're planning on changing Linux's Xen MSR helpers to mask the feature out, that should be in the same patch o

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin <h...@zytor.com> wrote: > On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski <l...@amacapital.net> > wrote: >>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <m...@kylehuey.com> wrote: >>> On Wed, Sep 14, 201

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote: > On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote: > On 15.09.16 at 12:05, wrote: >>> On 14/09/16 22:01, Kyle Huey wrote: Xen advertises the underlying support for CPUID

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: > On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen > wrote: >> On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Is any of this useful to optimize away at compile-time? We have config >> options for when

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Aug 9, 2016 7:09 PM, "James Bottomley" < james.bottom...@hansenpartnership.com> wrote: > > On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote: > > > table development go under copyleft-next, Rusty recently asked for > > > code to go in prior to the license tag being added denoting

[Xen-devel] [tip:x86/asm] x86/xen: Simplify set_aliased_prot()

Commit-ID: 99158f10e91768d34c5004c40c42f802b719bcae Gitweb: http://git.kernel.org/tip/99158f10e91768d34c5004c40c42f802b719bcae Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Tue, 24 May 2016 15:48:38 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat, 11

Re: [Xen-devel] [PATCH 1/7] x86/xen: Simplify set_aliased_prot

On Wed, May 25, 2016 at 2:50 AM, David Vrabel <david.vra...@citrix.com> wrote: > On 24/05/16 23:48, Andy Lutomirski wrote: >> In aa1acff356bb ("x86/xen: Probe target addresses in >> set_aliased_prot() before the hypercall"), I added an explicit probe >> to wor

[Xen-devel] [PATCH 1/7] x86/xen: Simplify set_aliased_prot

ky <boris.ostrov...@oracle.com> Cc: David Vrabel <dvra...@cantab.net> Cc: Jan Beulich <jbeul...@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: xen-devel <xen-devel@lists.xen.org> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/xen/enl

[Xen-devel] [tip:x86/asm] x86/extable: Add a comment about early exception handlers

Commit-ID: 60a0e2039e3df6c0a2b896bd78af36ff36fb629c Gitweb: http://git.kernel.org/tip/60a0e2039e3df6c0a2b896bd78af36ff36fb629c Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Mon, 4 Apr 2016 08:46:22 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/msr: Set the return value to zero when native_rdmsr_safe() fails

Commit-ID: b828b79fcced0e66492590707649dbfaea6435e6 Gitweb: http://git.kernel.org/tip/b828b79fcced0e66492590707649dbfaea6435e6 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:40 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/paravirt: Add paravirt_{read, write}_msr()

Commit-ID: dd2f4a004b016bbfb64f1de49cb45e66232e40a6 Gitweb: http://git.kernel.org/tip/dd2f4a004b016bbfb64f1de49cb45e66232e40a6 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:38 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y

Commit-ID: 4985ce15a397e9b6541548efe3b9ffac2dda9127 Gitweb: http://git.kernel.org/tip/4985ce15a397e9b6541548efe3b9ffac2dda9127 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:39 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/msr: Carry on after a non-"safe" MSR access fails

Commit-ID: fbd704374d111bed16a19261176fa30e2379c87c Gitweb: http://git.kernel.org/tip/fbd704374d111bed16a19261176fa30e2379c87c Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:37 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/head: Pass a real pt_regs and trapnr to early_fixup_exception()

Commit-ID: 7bbcdb1ca4d2fd69094ee89c18601b396531ca9f Gitweb: http://git.kernel.org/tip/7bbcdb1ca4d2fd69094ee89c18601b396531ca9f Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:32 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/paravirt: Add _safe to the read_ms()r and write_msr() PV callbacks

Commit-ID: c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed Gitweb: http://git.kernel.org/tip/c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:36 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/head: Move the early NMI fixup into C

Commit-ID: 0d0efc07f3df677d7622bb760f8e2920b5e33f42 Gitweb: http://git.kernel.org/tip/0d0efc07f3df677d7622bb760f8e2920b5e33f42 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:33 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/traps: Enable all exception handler callbacks early

Commit-ID: ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe Gitweb: http://git.kernel.org/tip/ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:35 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[Xen-devel] [tip:x86/asm] x86/head: Move early exception panic code into early_fixup_exception()

Commit-ID: 0e861fbb5bda79b871341ef2a9a8059765cbe8a4 Gitweb: http://git.kernel.org/tip/0e861fbb5bda79b871341ef2a9a8059765cbe8a4 Author: Andy Lutomirski <l...@kernel.org> AuthorDate: Sat, 2 Apr 2016 07:01:34 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Sun, Apr 10, 2016 at 10:12 PM, Juergen Gross wrote: > On 08/04/16 22:40, Luis R. Rodriguez wrote: >> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote: >>> On 06/04/16 03:40, Luis R. Rodriguez wrote: * You don't need full EFI emulation >>> >>> I think

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 08/04/2016 18:00, Andy Lutomirski wrote: >> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on &g

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On Fri, Apr 8, 2016 at 1:01 AM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 08/04/2016 01:24, Andy Lutomirski wrote: >> I can't see any reason that we need the __KERNEL_DS segment at all -- >> I think that everything that uses __KERNEL_DS could use __USER_DS >

[Xen-devel] Does __KERNEL_DS serve a purpose?

I can't see any reason that we need the __KERNEL_DS segment at all -- I think that everything that uses __KERNEL_DS could use __USER_DS instead. Am I missing anything? This has been bugging me for a while. I mulled over this a bit when trying to understand the sysret_ss_attrs bug and then

Re: [Xen-devel] Adding Xen to the kbuild bot?

On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang...@intel.com> wrote: >> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote: >>> On Feb 4, 2016 7:11 PM, "Fe

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Mon, Apr 4, 2016 at 12:38 PM, Borislav Petkov <b...@alien8.de> wrote: > On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote: >> On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote: >> >> > Adding locking would be easy enough, wouldn't it?

Re: [Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr

On Mon, Apr 4, 2016 at 9:33 AM, David Vrabel <david.vra...@citrix.com> wrote: > On 02/04/16 15:01, Andy Lutomirski wrote: >> This adds paravirt hooks for unsafe MSR access. On native, they >> call native_{read,write}_msr. On Xen, they use >> xen_{read,write}_msr_safe.

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sun, Apr 3, 2016 at 7:10 AM, Borislav Petkov <b...@alien8.de> wrote: > On Sun, Apr 03, 2016 at 06:55:00AM -0700, Andy Lutomirski wrote: >> > No, please don't fail at early boot. >> > >> > Early boot is just about the *worst* situation to try to debug odd >

[Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers

Borislav asked for a comment explaining why all exception handlers are allowed early. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/mm/extable.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 98b5f4

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Apr 4, 2016 4:51 AM, "Jan Kara" <j...@suse.cz> wrote: > > On Sat 02-04-16 13:58:19, Andy Lutomirski wrote: > > [cc Jan Kara] > > > > On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov <b...@alien8.de> wrote: > > > On Sat, Apr 02, 2016 at 01:13

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sun, Apr 3, 2016 at 6:51 AM, Linus Torvalds wrote: > On Sun, Apr 3, 2016 at 3:07 AM, Borislav Petkov wrote: >> >> I'm wondering whether making it try to EFAULT correctly is the right >> thing to do... We're certainly more conservative if we panic

Re: [Xen-devel] [PATCH v5 5/9] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

On Sun, Apr 3, 2016 at 1:41 AM, Borislav Petkov <b...@alien8.de> wrote: > On Sat, Apr 02, 2016 at 07:01:36AM -0700, Andy Lutomirski wrote: >> These hooks match the _safe variants, so name them accordingly. >> This will make room for unsafe PV hooks. >> >>

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sun, Apr 3, 2016 at 1:07 AM, Borislav Petkov <b...@alien8.de> wrote: > On Sat, Apr 02, 2016 at 10:52:48PM +0200, Borislav Petkov wrote: >> On Sat, Apr 02, 2016 at 01:16:07PM -0700, Andy Lutomirski wrote: >> > I have no idea why it was explicitly unsupported, but I'm g

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

[cc Jan Kara] On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov <b...@alien8.de> wrote: > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote: >> Given that I this isn't really a regression with my patches (it >> probably never worked much better on 32-bit and

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sat, Apr 2, 2016 at 11:52 AM, Borislav Petkov <b...@alien8.de> wrote: > On Sat, Apr 02, 2016 at 07:01:35AM -0700, Andy Lutomirski wrote: >> Now that early_fixup_exception has pt_regs, we can just call >> fixup_exception from it. This will make fancy exception h

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Sat, Apr 2, 2016 at 11:39 AM, Borislav Petkov <b...@alien8.de> wrote: > On Sat, Apr 02, 2016 at 07:01:34AM -0700, Andy Lutomirski wrote: >> This removes a bunch of assembly and adds some C code instead. It >> changes the actual printouts on both 32-bit and 64-bit kerne

Re: [Xen-devel] Getting rid of inside_vm in intel8x0

On Apr 2, 2016 12:07 PM, "Takashi Iwai" <ti...@suse.de> wrote: > > On Sat, 02 Apr 2016 14:57:44 +0200, > Andy Lutomirski wrote: > > > > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai <ti...@suse.de> wrote: > > > On Sat, 02 Apr 2016 00:28:31 +0200,

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

On Sat, Apr 2, 2016 at 7:24 AM, Linus Torvalds wrote: > This patch series looks much nicer than the last one. I assume you > tested that the early-trap handling actually worked too? I only looked > at the patches.. > > Ack to it all, I injected some BUGs in various

[Xen-devel] [PATCH v5 6/9] x86/msr: Carry on after a non-"safe" MSR access fails

VIRT=y bug in the non-"safe" MSR helpers gets fixed. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/include/asm/msr.h | 10 -- arch/x86/mm/extable.c | 27 +++ 2 files changed, 35 insertions(+), 2 deletions(-) diff --git a/arch/x8

[Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

(Ingo, sort of) Changes from earlier versions: lots of changes! Andy Lutomirski (9): x86/head: Pass a real pt_regs and trapnr to early_fixup_exception x86/head: Move the early NMI fixup into C x86/head: Move early exception panic code into early_fixup_exception x86/traps: Enable all exception

[Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr

think that should be done separately by the Xen maintainers. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/include/asm/msr.h| 5 +++-- arch/x86/include/asm/paravirt.h | 11 +++ arch/x86/include/asm/paravirt_types.h | 10 -- arch/x86/

[Xen-devel] [PATCH v5 1/9] x86/head: Pass a real pt_regs and trapnr to early_fixup_exception

early_fixup_exception is limited by the fact that it doesn't have a real struct pt_regs. Change both the 32-bit and 64-bit asm and the C code to pass and accept a real pt_regs. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- arch/x86/include/asm/uaccess.h | 2 +- arch/x86/kernel/hea

  1   2   3   4   >