I think you're saying, you only need to test one way:
if the non-VM code works and is just slow on a VM, then wouldn't it be
okay if there were some heuristic that were always right on bare metal
and mostly right on a VM?
Anyway, I still don't see what's wrong with just meas
This removes a bunch of assembly and adds some C code instead. It
changes the actual printouts on both 32-bit and 64-bit kernels, but
they still seem okay.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/uaccess.h | 2 +-
arch/x86/kernel/head_32.S | 49
Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr turned
into rdmsr_safe and wrmsr turned into wrmsr_safe, even on bare
metal. Undo that by using the new unsafe paravirt MSR hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 9 +++--
1 file changed, 3
This will cause unchecked native_rdmsr_safe failures to return
deterministic results.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 13da359881d7
These hooks match the _safe variants, so name them accordingly.
This will make room for unsafe PV hooks.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/paravirt.h | 33 +
arch/x86/include/asm/paravirt_types.h | 8
arch/x86/kernel
Now that early_fixup_exception has pt_regs, we can just call
fixup_exception from it. This will make fancy exception handlers
work early.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/extable.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/x86
C is nicer than asm.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/head_32.S | 7 ---
arch/x86/kernel/head_64.S | 6 --
arch/x86/mm/extable.c | 5 +
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index
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
---
arch/x86/include/asm/uaccess.h | 2 +-
arch/x86/kernel/head_32.S
VIRT=y bug in the non-"safe" MSR helpers
gets fixed.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h | 10 --
arch/x86/mm/extable.c | 27 +++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/msr.h b/
s/unsafe/unchecked/ (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:
n. I think that
should be done separately by the Xen maintainers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/msr.h| 5 +++--
arch/x86/include/asm/paravirt.h | 11 +++
arch/x86/include/asm/paravirt_types.h | 10 --
arch/x86/kernel/parav
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 places on 32-bit an 64-bit and
On Apr 2, 2016 12:07 PM, "Takashi Iwai" wrote:
>
> On Sat, 02 Apr 2016 14:57:44 +0200,
> Andy Lutomirski wrote:
> >
> > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai wrote:
> > > On Sat, 02 Apr 2016 00:28:31 +0200,
> > > Luis R. Rodriguez wrote:
&
On Sat, Apr 2, 2016 at 11:39 AM, Borislav Petkov 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 kernels, but
>>
On Sat, Apr 2, 2016 at 11:52 AM, Borislav Petkov 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 handlers
>> work early.
>
[cc Jan Kara]
On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov 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 the regs never would
On Sun, Apr 3, 2016 at 1:07 AM, Borislav Petkov 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 guessing it
On Sun, Apr 3, 2016 at 1:41 AM, Borislav Petkov 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.
>>
>> Signed-off-by: Andy Luto
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 and not
>> allow some silently failed attempt a
On Apr 4, 2016 4:51 AM, "Jan Kara" 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 wrote:
> > > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wro
Borislav asked for a comment explaining why all exception handlers are
allowed early.
Signed-off-by: Andy Lutomirski
---
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 98b5f45d9d79..36fe03bc81ee
On Sun, Apr 3, 2016 at 7:10 AM, Borislav Petkov 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
>> > failur
On Mon, Apr 4, 2016 at 9:33 AM, David Vrabel 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.
>>
>> Nothing us
On Mon, Apr 4, 2016 at 12:38 PM, Borislav Petkov 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?
>>
>>
On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski wrote:
> On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu wrote:
>> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" 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
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 forgot
On Fri, Apr 8, 2016 at 1:01 AM, Andrew Cooper 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
>> instead. Am I missin
On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini 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
>> this, since it o
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 needing any EFI em
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, t
On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
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_exit_mmap() at all
On Wed, Apr 26, 2017 at 5:55 PM, Boris Ostrovsky
wrote:
>
>
> On 04/26/2017 06:49 PM, Andy Lutomirski wrote:
>>
>> On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
>> wrote:
>>>
>>> On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
>>>>
>&
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 (this_cpu_read(xen_current_cr3) ==
On Thu, Apr 27, 2017 at 1:00 PM, Boris Ostrovsky
wrote:
> On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
>> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
>> wrote:
>>>>>>>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>>>>
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
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Signed-off-by: Andy Lutomirski
---
arch/x86/xen/multicalls.c
aking when PCID is enabled.
Cc: Tom Lendacky
Cc: Juergen Gross
Cc: xen-devel
Cc: Boris Ostrovsky
Signed-off-by: Andy Lutomirski
---
Hi Ingo-
I broke this out because Tom's SME series and my PCID series both need it.
Please consider applying it to tip:x86/mm.
I'll send PCID v2 soon.
On Tue, Jun 13, 2017 at 2:26 AM, Borislav Petkov 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 some of t
> 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%r11, (%rsp)
jne 1f
>
>>>
> 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%r11, (%rsp)
jne 1f
>
>>>
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 sensible
On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski 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 conso
On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski wrote:
> On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski 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/
On Wed, Nov 22, 2017 at 4:50 AM, Juergen Gross wrote:
> On 22/11/17 05:46, Andy Lutomirski wrote:
>> On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski wrote:
>>> On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski wrote:
>>>> I'm doing:
>>>>
>>
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 the Xen specific c
On Wed, Jul 26, 2017 at 7:01 AM, Andrew Cooper
wrote:
> On 26/07/17 14:48, Andy Lutomirski wrote:
>>
>>> /* Runs on exception stack */
>>> -ENTRY(nmi)
>>> - /*
>>> -* Fix up the exception frame if we're on Xen.
>>> -
> On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote:
>
>> On 26/07/17 15:48, Andy Lutomirski wrote:
>>> 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 add
> On Jul 26, 2017, at 2:43 PM, Juergen Gross wrote:
>
>> On 26/07/17 19:57, Andy Lutomirski wrote:
>>
>>
>>>> On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote:
>>>>
>>>>> On 26/07/17 15:48, Andy Lutomirski wrote:
>>
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 the Xen specific co
On Tue, Aug 1, 2017 at 4:38 PM, Andrew Cooper 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 the SYENTER entry on Xen PV.
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 @@ static void xen_write_ldt_
nefit 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
---
Changes from v1 (which I never actual
On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote:
> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote:
>> /* Normal 64-bit system call target */
>> ENTRY(xen_syscall_target)
>> - undo_xen_syscall
>> - jmp entry_SYSCALL_64_after_swapgs
>>
On Sun, Aug 13, 2017 at 10:53 PM, Andy Lutomirski wrote:
> On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote:
>> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote:
>>> /* Normal 64-bit system call target */
>>> ENTRY(xen_syscall_target)
>>> -
;)
Signed-off-by: Andy Lutomirski
---
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-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
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
> encryption mask in the read
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 we're running as a guest, and this seems like a fea
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 faulting but not does pass
through writes to the relevant
On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin wrote:
> On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski
> wrote:
>>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
On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
Reviewed-by: Andy Lutomirski
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 or a
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 | 1 +
> arch/x86/include/asm/proto.h
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
> http://www.intel.com/content/dam/www/public/us/en/document
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.
>
> Signed-off-by: Thom
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 wrote:
Can we use the read-only GDT here? When expanding the virtual
On Dec 2, 2016 3: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
> > guaranteed to serialize. (Even CPUID isn't *really* guaranteed to
> > serialize on Xen
On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper wrote:
> On 02/12/16 17:07, Andy Lutomirski wrote:
>> On Dec 2, 2016 3: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 are
On Dec 2, 2016 10:48 AM, "Boris Ostrovsky" 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
> >> guaranteed to seriali
: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/cpu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 4224ede43b4e..26240dde081e 100644
--- a/arch/x86/boot/cpu.c
very 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"
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 77
1 file changed,
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1". I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.
Reported-by: Henrique de Moraes Holschuh
Acked-by: Borislav Petkov
Signed-off-by: Andy
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/microcode/intel: Replace sync_core() with native_cpuid()
x
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
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 2 +-
1
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"
>>> > + "pushl $1f\n\t"
>>> > + "iret\n\t"
On Mon, Dec 5, 2016 at 11:52 PM, Borislav Petkov 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-self
>> in
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 this
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 forcefully update the pvti which wi
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 nit:
Acked-by: Andy Lut
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 header file, hence this commit
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 could target other per-cp
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;
>> + table_base = (unsigned long)get_current_direct_gd
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 always writes to the G
sync_core() comment.
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
: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/cpu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 4224ede43b4e..26240dde081e 100644
--- a/arch/x86/boot/cpu.c
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1". I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.
Reported-by: Henrique de Moraes Holschuh
Acked-by: Borislav Petkov
Signed-off-by: Andy
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
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 2 +-
1
very 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"
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/processor.h | 80 +---
1 file changed,
On Fri, Dec 9, 2016 at 10:24 AM, Andy Lutomirski 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 we
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 could target other per-cpu
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 always writes to the GD
On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper wrote:
> On 09/03/2017 21:32, Andy Lutomirski wrote:
>> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
>>
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -710,7 +710,7
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs)
On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" wrote:
>
>
>
> On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
>>
>> On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
>> wrote:
>>>
>>> After 32-bit syscall rewrite, and specifically after com
On Mon, Nov 16, 2015 at 8:25 AM, Boris Ostrovsky
wrote:
> On 11/15/2015 01:02 PM, Andy Lutomirski wrote:
>>
>> On Nov 13, 2015 5:23 PM, "Boris Ostrovsky"
>> wrote:
>>>
>>>
>>>
>>> On 11/13/2015 06:26 PM, Andy Lutomirsk
On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov wrote:
> On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote:
>
>> ...
>> The reader surely doesn't remember that this isn't guaranteed to be a
>> swapgs instruction on native. Using:
>>
>
On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky
wrote:
> On 11/16/2015 03:22 PM, Borislav Petkov wrote:
>>
>> On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote:
>>
>>> Are there really multiple feature bits for this stuff? I'd like to
>>&g
On Mon, Nov 16, 2015 at 1:03 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote:
>> On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky
>> wrote:
>> > On 11/16/2015 03:22 PM, Borislav Petkov wrote:
>> >>
>> &
On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote:
>
> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
>>
>> On 11/16/15 12:22, Borislav Petkov wrote:
>>>
>>> Huh, so what's wrong with a jump:
>>>
>>> jmp 1f
>>> swapgs
>>> 1:
>>>
>> What is the point of that jump?
>>
If i
On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
wrote:
> On 17/11/15 18:49, Andy Lutomirski wrote:
>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>> wrote:
>>> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
>>>> On 11/16/15 12:22, Borislav Petkov
On Tue, Nov 17, 2015 at 11:29 AM, Andrew Cooper
wrote:
> On 17/11/15 19:16, Andy Lutomirski wrote:
>> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
>> wrote:
>>> On 17/11/15 18:49, Andy Lutomirski wrote:
>>>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky&qu
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
wrote:
> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
wrote:
> Xen PV guests have been the only ones using it and now they don't.
Fantastic!
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
1 - 100 of 366 matches
Mail list logo
