Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >> On 28/12/2016 18:09, Roman Kagan wrote: >> > Am I correct assuming that QEMU is currently the only user of >> > arch/x86/include/uapi/asm/hyperv.h? >> >

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >> On 28/12/2016 18:09, Roman Kagan wrote: >> > Am I correct assuming that QEMU is currently the only user of >> > arch/x86/include/uapi/asm/hyperv.h? >> > >> > Then I think

Re: How should we handle variable address space sizes (Re: [RFC 3/4] x86/mm: define TASK_SIZE as current->mm->task_size)

On January 2, 2017 8:52:41 AM PST, Andy Lutomirski wrote: >On Mon, Jan 2, 2017 at 1:49 AM, Kirill A. Shutemov > wrote: >> On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote: >>> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov

Re: How should we handle variable address space sizes (Re: [RFC 3/4] x86/mm: define TASK_SIZE as current->mm->task_size)

On January 2, 2017 8:52:41 AM PST, Andy Lutomirski wrote: >On Mon, Jan 2, 2017 at 1:49 AM, Kirill A. Shutemov > wrote: >> On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote: >>> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov > wrote: >>> > Keep task's virtual address space size as

Re: [tip:x86/urgent] x86/tools: Fix gcc-7 warning in relocs.c

On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf wrote: >On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote: >> On 12/20/16 02:00, Markus Trippelsdorf wrote: >> > On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote: >> >> I'd strongly prefer a non-data-dependent

Re: [tip:x86/urgent] x86/tools: Fix gcc-7 warning in relocs.c

On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf wrote: >On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote: >> On 12/20/16 02:00, Markus Trippelsdorf wrote: >> > On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote: >> >> I'd strongly prefer a non-data-dependent solution, specifically

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote: > >The code is not calling CPUID in any performance critical path, only >at initialization. So any discussion about saving a few instructions >is a complete waste of time. > >-Andi NB: the chief offender is Loadlin,

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote: > >The code is not calling CPUID in any performance critical path, only >at initialization. So any discussion about saving a few instructions >is a complete waste of time. > >-Andi NB: the chief offender is Loadlin, which is still used in

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote: > >The code is not calling CPUID in any performance critical path, only >at initialization. So any discussion about saving a few instructions >is a complete waste of time. > >-Andi Sort of. The BIOS boot code is very

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote: > >The code is not calling CPUID in any performance critical path, only >at initialization. So any discussion about saving a few instructions >is a complete waste of time. > >-Andi Sort of. The BIOS boot code is very space-constrained for

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 6:39:44 AM PST, Borislav Petkov wrote: >On Wed, Dec 14, 2016 at 12:07:54AM +0100, Boris Petkov wrote: >> Thus I was thinking of adding a build-time check for the gcc version >> but that might turn out to be more code in the end than those ugly >> ifnc clauses.

Re: [RFC, PATCHv1 15/28] x86: detect 5-level paging support

On December 15, 2016 6:39:44 AM PST, Borislav Petkov wrote: >On Wed, Dec 14, 2016 at 12:07:54AM +0100, Boris Petkov wrote: >> Thus I was thinking of adding a build-time check for the gcc version >> but that might turn out to be more code in the end than those ugly >> ifnc clauses. > >IOW,

Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()

On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Gitweb: >http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Author: Josh Poimboeuf >AuthorDate: Tue, 13

Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()

On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Gitweb: >http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Author: Josh Poimboeuf >AuthorDate: Tue, 13 Dec 2016 21:25:35 -0600 >Committer:

Re: [RFC, PATCHv1 00/28] 5-level paging

On December 8, 2016 10:16:07 AM PST, Linus Torvalds wrote: >On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: >> >> This patchset is still very early. There are a number of things >missing >> that we have to do before

Re: [RFC, PATCHv1 00/28] 5-level paging

On December 8, 2016 10:16:07 AM PST, Linus Torvalds wrote: >On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: >> >> This patchset is still very early. There are a number of things >missing >> that we have to do before asking anyone to merge it (listed below). >> It would be great if

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 9:49:50 PM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> > It is tricky to do so safely, because at this stage almost nothing >of the C >> > execution environment has been set up. > >Yeah - but we do have a fair amount

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 9:49:50 PM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> > It is tricky to do so safely, because at this stage almost nothing >of the C >> > execution environment has been set up. > >Yeah - but we do have a fair amount of early C code though. > >> I can still give

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 8:08:55 AM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> On 12/02/2016 04:45 AM, Ingo Molnar wrote: >> > * Boris Ostrovsky wrote: >> > >> >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote: >>

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 8:08:55 AM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> On 12/02/2016 04:45 AM, Ingo Molnar wrote: >> > * Boris Ostrovsky wrote: >> > >> >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote: >> >>> >> >>> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote: >> From:

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On November 21, 2016 1:21:35 PM PST, Linus Torvalds wrote: >On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote: >> On 11/21/16 10:00, Linus Torvalds wrote: >>> >>> I'd much rather we go back to just making the "cs" entry explicitly >>> 16-bit,

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On November 21, 2016 1:21:35 PM PST, Linus Torvalds wrote: >On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote: >> On 11/21/16 10:00, Linus Torvalds wrote: >>> >>> I'd much rather we go back to just making the "cs" entry explicitly >>> 16-bit, and have a separate padding entry, the way we

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On November 19, 2016 5:52:57 PM PST, Andy Lutomirski wrote: >This is a question for the old-timers here, since I can't find >anything resembling an answer in the SDM. > >Suppose an exception happens (#UD in this case, but I assume it >doesn't really matter). We're not in long

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On November 19, 2016 5:52:57 PM PST, Andy Lutomirski wrote: >This is a question for the old-timers here, since I can't find >anything resembling an answer in the SDM. > >Suppose an exception happens (#UD in this case, but I assume it >doesn't really matter). We're not in long mode, and the IDT

Re: [PATCH] x86: avoid warning for zero-filling .bss

On November 17, 2016 1:02:48 PM PST, Josh Poimboeuf wrote: >On Wed, Nov 16, 2016 at 03:17:09PM +0100, Arnd Bergmann wrote: >> The latest binutils are warning about a .fill directive with an >explicit >> value in a .bss section: >> >> arch/x86/kernel/head_32.S: Assembler

Re: [PATCH] x86: avoid warning for zero-filling .bss

On November 17, 2016 1:02:48 PM PST, Josh Poimboeuf wrote: >On Wed, Nov 16, 2016 at 03:17:09PM +0100, Arnd Bergmann wrote: >> The latest binutils are warning about a .fill directive with an >explicit >> value in a .bss section: >> >> arch/x86/kernel/head_32.S: Assembler messages: >>

Re: [PATCH] kconfig.h: remove config_enabled() macro

On October 16, 2016 4:07:58 AM PDT, Masahiro Yamada wrote: >The use of config_enabled() is ambiguous. For config options, >IS_ENABLED(), IS_REACHABLE(), etc. will make intention clearer. >Sometimes config_enabled() has been used for non-config options >because it

Re: [PATCH] kconfig.h: remove config_enabled() macro

On October 16, 2016 4:07:58 AM PDT, Masahiro Yamada wrote: >The use of config_enabled() is ambiguous. For config options, >IS_ENABLED(), IS_REACHABLE(), etc. will make intention clearer. >Sometimes config_enabled() has been used for non-config options >because it is useful to check whether the

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

On October 16, 2016 9:35:57 AM PDT, Borislav Petkov wrote: >On Sun, Oct 16, 2016 at 09:02:51AM -0700, h...@zytor.com wrote: >> No, please. That would be worse than the disease. > >Why not? > >I did that recently with a bunch of leaves and there were no issues: > >2ccd71f1b278

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

On October 16, 2016 9:35:57 AM PDT, Borislav Petkov wrote: >On Sun, Oct 16, 2016 at 09:02:51AM -0700, h...@zytor.com wrote: >> No, please. That would be worse than the disease. > >Why not? > >I did that recently with a bunch of leaves and there were no issues: > >2ccd71f1b278 ("x86/cpufeature:

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

On October 16, 2016 7:22:33 AM PDT, Borislav Petkov wrote: >On Sun, Oct 16, 2016 at 04:21:49AM -0700, tip-bot for Piotr Luc wrote: >> Commit-ID: a518dcc82b6162009c8ca3d169fe61c81536ff17 >> Gitweb: >http://git.kernel.org/tip/a518dcc82b6162009c8ca3d169fe61c81536ff17 >> Author:

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

On October 16, 2016 7:22:33 AM PDT, Borislav Petkov wrote: >On Sun, Oct 16, 2016 at 04:21:49AM -0700, tip-bot for Piotr Luc wrote: >> Commit-ID: a518dcc82b6162009c8ca3d169fe61c81536ff17 >> Gitweb: >http://git.kernel.org/tip/a518dcc82b6162009c8ca3d169fe61c81536ff17 >> Author: Piotr Luc

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky wrote: >On 10/14/2016 02:31 PM, h...@zytor.com wrote: >> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky > wrote: >>> From: Matt Fleming >>> >>> The new

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky wrote: >On 10/14/2016 02:31 PM, h...@zytor.com wrote: >> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky > wrote: >>> From: Matt Fleming >>> >>> The new Xen PVH entry point requires page tables to be setup by the >>> kernel since it is

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky wrote: >From: Matt Fleming > >The new Xen PVH entry point requires page tables to be setup by the >kernel since it is entered with paging disabled. > >Pull the common code out of head_32.S

Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky wrote: >From: Matt Fleming > >The new Xen PVH entry point requires page tables to be setup by the >kernel since it is entered with paging disabled. > >Pull the common code out of head_32.S and into pgtable_32.S so that >setup_pgtable_32 can

Re: [RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

on,-march=bonnell,$(call >cc-option,-march=core2,-march=i686)) \ >+ $(call cc-option,-mtune=bonnell,$(call cc-option,-mtune=generic)) > > # AMD Elan support > cflags-$(CONFIG_MELAN)+= -march=i486 This just breaks backwards compatibility with older gcc. If you want to add a comment that's fine, though. Nacked-by: hpa -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

gt;+ $(call cc-option,-mtune=bonnell,$(call cc-option,-mtune=generic)) > > # AMD Elan support > cflags-$(CONFIG_MELAN)+= -march=i486 This just breaks backwards compatibility with older gcc. If you want to add a comment that's fine, though. Nacked-by: hpa -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

<    1   2   3   4   5