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 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 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
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 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
>
>>>
;)
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 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)
>>> -
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
>>
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 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_
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 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 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 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 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 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 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 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
Commit-ID: 6c690ee1039b251e583fc65b28da30e97d6a7385
Gitweb: http://git.kernel.org/tip/6c690ee1039b251e583fc65b28da30e97d6a7385
Author: Andy Lutomirski
AuthorDate: Mon, 12 Jun 2017 10:26:14 -0700
Committer: Ingo Molnar
CommitDate: Tue, 13 Jun 2017 08:48:09 +0200
x86/mm: Split read_cr3
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.
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
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:
>>>>>
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 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 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
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 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 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 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 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 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 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
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:
> 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
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 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
Commit-ID: 484d0e5c7943644cc46e7308a8f9d83be598f2b9
Gitweb: http://git.kernel.org/tip/484d0e5c7943644cc46e7308a8f9d83be598f2b9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:07 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/microcode/intel
Commit-ID: c198b121b1a1d7a7171770c634cd49191bac4477
Gitweb: http://git.kernel.org/tip/c198b121b1a1d7a7171770c634cd49191bac4477
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:08 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/asm: Rewrite
Commit-ID: 426d1aff3138cf38da14e912df3c75e312f96e9e
Gitweb: http://git.kernel.org/tip/426d1aff3138cf38da14e912df3c75e312f96e9e
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:06 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
Revert "x86
Commit-ID: 1c52d859cb2d417e7216d3e56bb7fea88444cec9
Gitweb: http://git.kernel.org/tip/1c52d859cb2d417e7216d3e56bb7fea88444cec9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:05 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
x86/asm/32: Make
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
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,
: 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
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
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 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"
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
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
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
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,
: 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
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
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 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 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 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:
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 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 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 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 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
Commit-ID: 99158f10e91768d34c5004c40c42f802b719bcae
Gitweb: http://git.kernel.org/tip/99158f10e91768d34c5004c40c42f802b719bcae
Author: Andy Lutomirski
AuthorDate: Tue, 24 May 2016 15:48:38 -0700
Committer: Ingo Molnar
CommitDate: Sat, 11 Jun 2016 11:28:11 +0200
x86/xen: Simplify
On Wed, May 25, 2016 at 2:50 AM, David Vrabel 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 work around a hypercall issue.
Cc: Konrad Rzeszutek Wilk
Cc: xen-devel
Signed-off-by: Andy Lutomirski
---
arch/x86/xen/enlighten.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6ab672233ac9..eed696c229ba 100644
--- a/arch/x86/xen/enlighten.c
Commit-ID: 60a0e2039e3df6c0a2b896bd78af36ff36fb629c
Gitweb: http://git.kernel.org/tip/60a0e2039e3df6c0a2b896bd78af36ff36fb629c
Author: Andy Lutomirski
AuthorDate: Mon, 4 Apr 2016 08:46:22 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:47 +0200
x86/extable: Add a
Commit-ID: b828b79fcced0e66492590707649dbfaea6435e6
Gitweb: http://git.kernel.org/tip/b828b79fcced0e66492590707649dbfaea6435e6
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:40 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200
x86/msr: Set the return
Commit-ID: dd2f4a004b016bbfb64f1de49cb45e66232e40a6
Gitweb: http://git.kernel.org/tip/dd2f4a004b016bbfb64f1de49cb45e66232e40a6
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:38 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200
x86/paravirt: Add
Commit-ID: 4985ce15a397e9b6541548efe3b9ffac2dda9127
Gitweb: http://git.kernel.org/tip/4985ce15a397e9b6541548efe3b9ffac2dda9127
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:39 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200
x86/paravirt: Make
Commit-ID: fbd704374d111bed16a19261176fa30e2379c87c
Gitweb: http://git.kernel.org/tip/fbd704374d111bed16a19261176fa30e2379c87c
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:37 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200
x86/msr: Carry on after
Commit-ID: 7bbcdb1ca4d2fd69094ee89c18601b396531ca9f
Gitweb: http://git.kernel.org/tip/7bbcdb1ca4d2fd69094ee89c18601b396531ca9f
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:32 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200
x86/head: Pass a real
Commit-ID: c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed
Gitweb: http://git.kernel.org/tip/c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:36 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200
x86/paravirt: Add _safe
Commit-ID: ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe
Gitweb: http://git.kernel.org/tip/ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:35 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200
x86/traps: Enable all
Commit-ID: 0e861fbb5bda79b871341ef2a9a8059765cbe8a4
Gitweb: http://git.kernel.org/tip/0e861fbb5bda79b871341ef2a9a8059765cbe8a4
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:34 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200
x86/head: Move early
Commit-ID: 0d0efc07f3df677d7622bb760f8e2920b5e33f42
Gitweb: http://git.kernel.org/tip/0d0efc07f3df677d7622bb760f8e2920b5e33f42
Author: Andy Lutomirski
AuthorDate: Sat, 2 Apr 2016 07:01:33 -0700
Committer: Ingo Molnar
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200
x86/head: Move the early
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
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 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
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 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:
>>> >
>>> >
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 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 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
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 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
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 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 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
[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 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.
>
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 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 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
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
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
1 - 100 of 366 matches
Mail list logo
