Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Ingo Molnar]

* Russell King - ARM Linux  wrote:

> On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> > On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > > This header file is exported, thus move it to uapi.
> > 
> > Why? Why is this damn thing exported in the first place?
> > 
> > The moment we decide to change an MSR name or even remove it from that
> > file, we break userspace. And what for, because userspace is using some
> > arbitrary header file which was meant to be for the kernel solely.
> > 
> > NAKed-by: Borislav Petkov 
> 
> Here on my Fedora system:
> 
> $ less /usr/include/asm/msr-index.h
> #ifndef _ASM_X86_MSR_INDEX_H
> #define _ASM_X86_MSR_INDEX_H
> 
> /* CPU model specific register (MSR) numbers */
> 
> /* x86-64 specific MSRs */
> #define MSR_EFER0xc080 /* extended feature register */
> #define MSR_STAR0xc081 /* legacy mode SYSCALL target */
> #define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
> ...
> 
> Like it or not, it is _already_ exported to userspace, so it forms
> part of the user ABI.

Firstly, I believe you are (very!) confused about what forms part of the Linux 
user-space ABI - it's not the exported headers but the functionality and how 
application _binaries_ rely on it. We have strong ABI guarantees that are in no 
header anywhere. And we have tons and tons of details in UAPI headers that are 
not 
part of any system call ABI (or protocol ABI) of Linux.

Note that for example the 'MSR_STAR' definition you quote above is not part of 
the 
ABI, because user-space _cannot make use of it_: it's a privileged CPU register 
that only the kernel can write to. There's no system call ABI that Linux 
defines 
that this MSR (or any other MSR for that matter) are part of.

These MSR headers are not part of the ABI - they are part of the _mechanism_ 
trying to inform user-space about ABIs and people trying to somehow claim that 
they are an ABI are confused IMHO.

The point with msr-index.h is that there's no user-space ABI where those MSRs 
are 
enumerated.

Secondly, ABI means 'Application Binary Interface' - note the 'Binary' part. 
The 
ABI cannot be broken, by definition, by putting a header into another place. 
Now 
we do export UAPI headers and we definitely don't want to break user-space 
tooling 
if we can avoid it, but trying to spin the UAPI headers mechanism into an "ABI" 
is 
confused on so many levels.


I.e. this whole discussion is silly in the extreme. The point of the UAPI 
exports 
is to clean up our ABI exports, after we used to export _all_ headers to 
user-space.

I.e. by definition the UAPI mechanism is fundamentally about _restricting_ the 
amount of headers that are exposed - separating true ABI from random kernel 
internals. This process of enumerating ABI details separately from kernel 
implementation internal details improves the kernel headers.

> [...]  You can try to remove it from userspace view, but if anyone has 
> already 
> started to use it, removing it will already cause a userspace regression.

I challenge you to show a single user-space regression from the removal of the 
'MSR_STAR' definition for example.

Please explain, why do you want to export msr-index.h and which part of it is 
an 
'ABI' in your opinion? Until you can explain that my NAK stands.

Thanks,

Ingo

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Ingo Molnar]

* Russell King - ARM Linux  wrote:

> On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> > On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > > This header file is exported, thus move it to uapi.
> > 
> > Why? Why is this damn thing exported in the first place?
> > 
> > The moment we decide to change an MSR name or even remove it from that
> > file, we break userspace. And what for, because userspace is using some
> > arbitrary header file which was meant to be for the kernel solely.
> > 
> > NAKed-by: Borislav Petkov 
> 
> Here on my Fedora system:
> 
> $ less /usr/include/asm/msr-index.h
> #ifndef _ASM_X86_MSR_INDEX_H
> #define _ASM_X86_MSR_INDEX_H
> 
> /* CPU model specific register (MSR) numbers */
> 
> /* x86-64 specific MSRs */
> #define MSR_EFER0xc080 /* extended feature register */
> #define MSR_STAR0xc081 /* legacy mode SYSCALL target */
> #define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
> ...
> 
> Like it or not, it is _already_ exported to userspace, so it forms
> part of the user ABI.

Firstly, I believe you are (very!) confused about what forms part of the Linux 
user-space ABI - it's not the exported headers but the functionality and how 
application _binaries_ rely on it. We have strong ABI guarantees that are in no 
header anywhere. And we have tons and tons of details in UAPI headers that are 
not 
part of any system call ABI (or protocol ABI) of Linux.

Note that for example the 'MSR_STAR' definition you quote above is not part of 
the 
ABI, because user-space _cannot make use of it_: it's a privileged CPU register 
that only the kernel can write to. There's no system call ABI that Linux 
defines 
that this MSR (or any other MSR for that matter) are part of.

These MSR headers are not part of the ABI - they are part of the _mechanism_ 
trying to inform user-space about ABIs and people trying to somehow claim that 
they are an ABI are confused IMHO.

The point with msr-index.h is that there's no user-space ABI where those MSRs 
are 
enumerated.

Secondly, ABI means 'Application Binary Interface' - note the 'Binary' part. 
The 
ABI cannot be broken, by definition, by putting a header into another place. 
Now 
we do export UAPI headers and we definitely don't want to break user-space 
tooling 
if we can avoid it, but trying to spin the UAPI headers mechanism into an "ABI" 
is 
confused on so many levels.


I.e. this whole discussion is silly in the extreme. The point of the UAPI 
exports 
is to clean up our ABI exports, after we used to export _all_ headers to 
user-space.

I.e. by definition the UAPI mechanism is fundamentally about _restricting_ the 
amount of headers that are exposed - separating true ABI from random kernel 
internals. This process of enumerating ABI details separately from kernel 
implementation internal details improves the kernel headers.

> [...]  You can try to remove it from userspace view, but if anyone has 
> already 
> started to use it, removing it will already cause a userspace regression.

I challenge you to show a single user-space regression from the removal of the 
'MSR_STAR' definition for example.

Please explain, why do you want to export msr-index.h and which part of it is 
an 
'ABI' in your opinion? Until you can explain that my NAK stands.

Thanks,

Ingo

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

Le 30/01/2017 à 15:51, Russell King - ARM Linux a écrit :
> On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
>> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
>>> This header file is exported, thus move it to uapi.
>>
>> Why? Why is this damn thing exported in the first place?
>>
>> The moment we decide to change an MSR name or even remove it from that
>> file, we break userspace. And what for, because userspace is using some
>> arbitrary header file which was meant to be for the kernel solely.
>>
>> NAKed-by: Borislav Petkov 
> 
> Here on my Fedora system:
> 
> $ less /usr/include/asm/msr-index.h
> #ifndef _ASM_X86_MSR_INDEX_H
> #define _ASM_X86_MSR_INDEX_H
> 
> /* CPU model specific register (MSR) numbers */
> 
> /* x86-64 specific MSRs */
> #define MSR_EFER0xc080 /* extended feature register */
> #define MSR_STAR0xc081 /* legacy mode SYSCALL target */
> #define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
> ...
> 
> Like it or not, it is _already_ exported to userspace, so it forms
> part of the user ABI.  You can try to remove it from userspace view,
> but if anyone has already started to use it, removing it will already
> cause a userspace regression.
> 
> So, I don't think we have any grounds to NAK these patches on the
> basis of "we don't want this to be visible to userspace because it
> may cause a userspace regression."  Removing it from userspace view
> is likely to cause a userspace regression.
> 
> This patch just makes sure that such a regression doesn't happen when
> kbuild stops exporting files in _non_-uapi directories.
Yes, it was the only goal. My patch changes nothing!
Is it possible to find a consensus about this patch?
Ingo ?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

Le 30/01/2017 à 15:51, Russell King - ARM Linux a écrit :
> On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
>> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
>>> This header file is exported, thus move it to uapi.
>>
>> Why? Why is this damn thing exported in the first place?
>>
>> The moment we decide to change an MSR name or even remove it from that
>> file, we break userspace. And what for, because userspace is using some
>> arbitrary header file which was meant to be for the kernel solely.
>>
>> NAKed-by: Borislav Petkov 
> 
> Here on my Fedora system:
> 
> $ less /usr/include/asm/msr-index.h
> #ifndef _ASM_X86_MSR_INDEX_H
> #define _ASM_X86_MSR_INDEX_H
> 
> /* CPU model specific register (MSR) numbers */
> 
> /* x86-64 specific MSRs */
> #define MSR_EFER0xc080 /* extended feature register */
> #define MSR_STAR0xc081 /* legacy mode SYSCALL target */
> #define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
> ...
> 
> Like it or not, it is _already_ exported to userspace, so it forms
> part of the user ABI.  You can try to remove it from userspace view,
> but if anyone has already started to use it, removing it will already
> cause a userspace regression.
> 
> So, I don't think we have any grounds to NAK these patches on the
> basis of "we don't want this to be visible to userspace because it
> may cause a userspace regression."  Removing it from userspace view
> is likely to cause a userspace regression.
> 
> This patch just makes sure that such a regression doesn't happen when
> kbuild stops exporting files in _non_-uapi directories.
Yes, it was the only goal. My patch changes nothing!
Is it possible to find a consensus about this patch?
Ingo ?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 30, 2017 at 02:51:51PM +, Russell King - ARM Linux wrote:
> Like it or not, it is _already_ exported to userspace, so it forms

Well, I did try to stop it then too:

  b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
API headers")

And yet this wankery trickled out to userspace anyway.

> part of the user ABI.  You can try to remove it from userspace view,
> but if anyone has already started to use it, removing it will already
> cause a userspace regression.

Well, if it were me, I'd still remove the header and see if anything
breaks.

If it does - which I doubt very much - we can do Christoph's idea of
leaving the current version of the header exported but then untangling
it from the whole uapi crap and use our own kernel version which we can
change as much as we can.

In the end of the day, it is a maintainer decision what's going to
happen.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 30, 2017 at 02:51:51PM +, Russell King - ARM Linux wrote:
> Like it or not, it is _already_ exported to userspace, so it forms

Well, I did try to stop it then too:

  b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
API headers")

And yet this wankery trickled out to userspace anyway.

> part of the user ABI.  You can try to remove it from userspace view,
> but if anyone has already started to use it, removing it will already
> cause a userspace regression.

Well, if it were me, I'd still remove the header and see if anything
breaks.

If it does - which I doubt very much - we can do Christoph's idea of
leaving the current version of the header exported but then untangling
it from the whole uapi crap and use our own kernel version which we can
change as much as we can.

In the end of the day, it is a maintainer decision what's going to
happen.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
> 
> NAKed-by: Borislav Petkov 

Here on my Fedora system:

$ less /usr/include/asm/msr-index.h
#ifndef _ASM_X86_MSR_INDEX_H
#define _ASM_X86_MSR_INDEX_H

/* CPU model specific register (MSR) numbers */

/* x86-64 specific MSRs */
#define MSR_EFER0xc080 /* extended feature register */
#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
...

Like it or not, it is _already_ exported to userspace, so it forms
part of the user ABI.  You can try to remove it from userspace view,
but if anyone has already started to use it, removing it will already
cause a userspace regression.

So, I don't think we have any grounds to NAK these patches on the
basis of "we don't want this to be visible to userspace because it
may cause a userspace regression."  Removing it from userspace view
is likely to cause a userspace regression.

This patch just makes sure that such a regression doesn't happen when
kbuild stops exporting files in _non_-uapi directories.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
> 
> NAKed-by: Borislav Petkov 

Here on my Fedora system:

$ less /usr/include/asm/msr-index.h
#ifndef _ASM_X86_MSR_INDEX_H
#define _ASM_X86_MSR_INDEX_H

/* CPU model specific register (MSR) numbers */

/* x86-64 specific MSRs */
#define MSR_EFER0xc080 /* extended feature register */
#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
...

Like it or not, it is _already_ exported to userspace, so it forms
part of the user ABI.  You can try to remove it from userspace view,
but if anyone has already started to use it, removing it will already
cause a userspace regression.

So, I don't think we have any grounds to NAK these patches on the
basis of "we don't want this to be visible to userspace because it
may cause a userspace regression."  Removing it from userspace view
is likely to cause a userspace regression.

This patch just makes sure that such a regression doesn't happen when
kbuild stops exporting files in _non_-uapi directories.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Thu, Jan 26, 2017 at 08:04:52PM +0100, Ingo Molnar wrote:
> Please remove this patch from linux-next as well, until you get an
> Acked-by from an x86 maintainer.

... and the header export from arch/x86/include/uapi/asm/Kbuild too pls.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Thu, Jan 26, 2017 at 08:04:52PM +0100, Ingo Molnar wrote:
> Please remove this patch from linux-next as well, until you get an
> Acked-by from an x86 maintainer.

... and the header export from arch/x86/include/uapi/asm/Kbuild too pls.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Ingo Molnar]

* Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.
> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/x86/include/asm/msr-index.h  | 698 
> --
>  arch/x86/include/uapi/asm/msr-index.h | 698 
> ++

For the reasons Boris outlined:

  NAKed-by: Ingo Molnar 

Please remove this patch from linux-next as well, until you get an Acked-by 
from 
an x86 maintainer.

Thanks,

Ingo

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Ingo Molnar]

* Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.
> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/x86/include/asm/msr-index.h  | 698 
> --
>  arch/x86/include/uapi/asm/msr-index.h | 698 
> ++

For the reasons Boris outlined:

  NAKed-by: Ingo Molnar 

Please remove this patch from linux-next as well, until you get an Acked-by 
from 
an x86 maintainer.

Thanks,

Ingo

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

Le 23/01/2017 à 18:26, Borislav Petkov a écrit :
> On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
> 
> Yeah, that's a good idea, thanks Christoph.
> 
> I guess we'll have to do that if something in userspace has put its
> sticky fingers on that file and cannot be fixed. Which I hardly doubt
> but we can't break that damn userspace.
> 
So do you agree with the current patch (a build-fix is also needed :/)?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

Le 23/01/2017 à 18:26, Borislav Petkov a écrit :
> On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
> 
> Yeah, that's a good idea, thanks Christoph.
> 
> I guess we'll have to do that if something in userspace has put its
> sticky fingers on that file and cannot be fixed. Which I hardly doubt
> but we can't break that damn userspace.
> 
So do you agree with the current patch (a build-fix is also needed :/)?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 11:24:02PM +0100, Jan Engelhardt wrote:
> So if some userspace component depends on that particular msr header
> (which, unlike ipt_SAME, was not intended for export), is it not
> reasonable to expect them to make a copy if and when they need it?

Yeah, either copy the whole header or better yet use own defines.
Especially in this particular case, where we have a bunch of MSRs which
are in the processor manuals. Exporting the defines is pretty pointless
and even disadvantageous for the kernel.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 11:24:02PM +0100, Jan Engelhardt wrote:
> So if some userspace component depends on that particular msr header
> (which, unlike ipt_SAME, was not intended for export), is it not
> reasonable to expect them to make a copy if and when they need it?

Yeah, either copy the whole header or better yet use own defines.
Especially in this particular case, where we have a bunch of MSRs which
are in the processor manuals. Exporting the defines is pretty pointless
and even disadvantageous for the kernel.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Jan Engelhardt]

On Monday 2017-01-23 18:26, Borislav Petkov wrote:

>On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
>
>I guess we'll have to do that if something in userspace has put its
>sticky fingers on that file and cannot be fixed. Which I hardly doubt
>but we can't break that damn userspace.

The importance of uapi headers presence is a bit overrated.

If you look at, for example, iptables (and further projects in that 
area), copies of uapi headers have been made (and this process is likely 
to continue) because it could be compiled on a variety of vintage 
systems that do not have all required #defines yet.

Similarly, it may be built on a variety of _modern_ systems whose 
kernels no longer have a particular thing (e.g. ipt_SAME), so it also 
ships copies of those headers.

So if some userspace component depends on that particular msr header (which,
unlike ipt_SAME, was not intended for export), is it not reasonable to expect
them to make a copy if and when they need it?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Jan Engelhardt]

On Monday 2017-01-23 18:26, Borislav Petkov wrote:

>On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
>
>I guess we'll have to do that if something in userspace has put its
>sticky fingers on that file and cannot be fixed. Which I hardly doubt
>but we can't break that damn userspace.

The importance of uapi headers presence is a bit overrated.

If you look at, for example, iptables (and further projects in that 
area), copies of uapi headers have been made (and this process is likely 
to continue) because it could be compiled on a variety of vintage 
systems that do not have all required #defines yet.

Similarly, it may be built on a variety of _modern_ systems whose 
kernels no longer have a particular thing (e.g. ipt_SAME), so it also 
ships copies of those headers.

So if some userspace component depends on that particular msr header (which,
unlike ipt_SAME, was not intended for export), is it not reasonable to expect
them to make a copy if and when they need it?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: x86_64-randconfig-s1-01240145 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: error: msr-index.h: No such file or 
>> directory
   In file included from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
   arch/x86/include/asm/processor.h: In function 'get_debugctlmsr':
>> arch/x86/include/asm/processor.h:719: error: 'MSR_IA32_DEBUGCTLMSR' 
>> undeclared (first use in this function)
   arch/x86/include/asm/processor.h:719: error: (Each undeclared identifier is 
reported only once
   arch/x86/include/asm/processor.h:719: error: for each function it appears 
in.)
   arch/x86/include/asm/processor.h: In function 'update_debugctlmsr':
   arch/x86/include/asm/processor.h:730: error: 'MSR_IA32_DEBUGCTLMSR' 
undeclared (first use in this function)
   In file included from arch/x86/include/asm/smp.h:12,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
   arch/x86/include/asm/apic.h: In function 'apic_is_x2apic_enabled':
>> arch/x86/include/asm/apic.h:116: error: 'MSR_IA32_APICBASE' undeclared 
>> (first use in this function)
   At top level:
   cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized"
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: x86_64-randconfig-s1-01240145 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: error: msr-index.h: No such file or 
>> directory
   In file included from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
   arch/x86/include/asm/processor.h: In function 'get_debugctlmsr':
>> arch/x86/include/asm/processor.h:719: error: 'MSR_IA32_DEBUGCTLMSR' 
>> undeclared (first use in this function)
   arch/x86/include/asm/processor.h:719: error: (Each undeclared identifier is 
reported only once
   arch/x86/include/asm/processor.h:719: error: for each function it appears 
in.)
   arch/x86/include/asm/processor.h: In function 'update_debugctlmsr':
   arch/x86/include/asm/processor.h:730: error: 'MSR_IA32_DEBUGCTLMSR' 
undeclared (first use in this function)
   In file included from arch/x86/include/asm/smp.h:12,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
   arch/x86/include/asm/apic.h: In function 'apic_is_x2apic_enabled':
>> arch/x86/include/asm/apic.h:116: error: 'MSR_IA32_APICBASE' undeclared 
>> (first use in this function)
   At top level:
   cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized"
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20:0,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: fatal error: msr-index.h: No such file or 
>> directory
#include "msr-index.h"
  ^
   compilation terminated.
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/uapi-export-all-headers-under-uapi-directories/20170124-011935
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/processor.h:20:0,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:8:
>> arch/x86/include/asm/msr.h:4:23: fatal error: msr-index.h: No such file or 
>> directory
#include "msr-index.h"
  ^
   compilation terminated.
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 arch/x86/include/asm/msr.h

1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   1  
#ifndef _ASM_X86_MSR_H
1965aae3 arch/x86/include/asm/msr.h H. Peter Anvin2008-10-22   2  
#define _ASM_X86_MSR_H
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   3  
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  @4  
#include "msr-index.h"
be7baf80 include/asm-x86/msr.h  Thomas Gleixner   2007-10-23   5  
8f12dea6 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   6  
#ifndef __ASSEMBLY__
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   7  
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   8  
#include 
c210d249 include/asm-x86/msr.h  Glauber de Oliveira Costa 2008-01-30   9  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  10  
#include 
b72e7464 arch/x86/include/asm/msr.h Borislav Petkov   2015-06-04  11  
#include 
6bc1096d arch/x86/include/asm/msr.h Borislav Petkov   2009-05-22  12  

:: The code at line 4 was first introduced by commit
:: b72e7464e4cf80117938e6adb8c22fdc1ca46d42 x86/uapi: Do not export 
 as part of the user API headers

:: TO: Borislav Petkov 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
> Or keep the exported version as-is and never changed it, and use
> a different copy for the kernel itself.

Yeah, that's a good idea, thanks Christoph.

I guess we'll have to do that if something in userspace has put its
sticky fingers on that file and cannot be fixed. Which I hardly doubt
but we can't break that damn userspace.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
> Or keep the exported version as-is and never changed it, and use
> a different copy for the kernel itself.

Yeah, that's a good idea, thanks Christoph.

I guess we'll have to do that if something in userspace has put its
sticky fingers on that file and cannot be fixed. Which I hardly doubt
but we can't break that damn userspace.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 06:17:32PM +0100, Borislav Petkov wrote:
> I know, we should not ever break userspace but if it were me, I'd remove
> that export and see what breaks. If at all.

Or keep the exported version as-is and never changed it, and use
a different copy for the kernel itself.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Christoph Hellwig]

On Mon, Jan 23, 2017 at 06:17:32PM +0100, Borislav Petkov wrote:
> I know, we should not ever break userspace but if it were me, I'd remove
> that export and see what breaks. If at all.

Or keep the exported version as-is and never changed it, and use
a different copy for the kernel itself.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 06:06:52PM +0100, Nicolas Dichtel wrote:
> After digging a bit, it seems you have already tried to remove it in commit
> b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
> API
> headers"), but because this file is still listed in the Kbuild file, it is 
> still
> exported.

Oh great. :-\

> It would be great if we could find a consensus about what to do with
> this file because it blocks patch #4 and the rest of the series.

The reasoning in b72e7464e4cf was valid then and is valid now. This
thing should not have been exported in the first place. And it's not
like I didn't try then. Dammit!

I know, we should not ever break userspace but if it were me, I'd remove
that export and see what breaks. If at all.

But let's see what the others think first.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 06:06:52PM +0100, Nicolas Dichtel wrote:
> After digging a bit, it seems you have already tried to remove it in commit
> b72e7464e4cf ("x86/uapi: Do not export  as part of the user 
> API
> headers"), but because this file is still listed in the Kbuild file, it is 
> still
> exported.

Oh great. :-\

> It would be great if we could find a consensus about what to do with
> this file because it blocks patch #4 and the rest of the series.

The reasoning in b72e7464e4cf was valid then and is valid now. This
thing should not have been exported in the first place. And it's not
like I didn't try then. Dammit!

I know, we should not ever break userspace but if it were me, I'd remove
that export and see what breaks. If at all.

But let's see what the others think first.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

+ Peter Anvin and Ingo Molnar

Le 23/01/2017 à 17:52, Borislav Petkov a écrit :
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
>> This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
It is exported because it is listed in arch/x86/include/uapi/asm/Kbuild:
header-y += msr-index.h (see also patch #4).

> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
I understand your concerns but my patch does not change anything. And I think
David's comment is right: if I remove it, I break the uapi.

After digging a bit, it seems you have already tried to remove it in commit
b72e7464e4cf ("x86/uapi: Do not export  as part of the user API
headers"), but because this file is still listed in the Kbuild file, it is still
exported.

It would be great if we could find a consensus about what to do with this file
because it blocks patch #4 and the rest of the series.


Thank you,
Nicolas

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

+ Peter Anvin and Ingo Molnar

Le 23/01/2017 à 17:52, Borislav Petkov a écrit :
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
>> This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
It is exported because it is listed in arch/x86/include/uapi/asm/Kbuild:
header-y += msr-index.h (see also patch #4).

> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
I understand your concerns but my patch does not change anything. And I think
David's comment is right: if I remove it, I break the uapi.

After digging a bit, it seems you have already tried to remove it in commit
b72e7464e4cf ("x86/uapi: Do not export  as part of the user API
headers"), but because this file is still listed in the Kbuild file, it is still
exported.

It would be great if we could find a consensus about what to do with this file
because it blocks patch #4 and the rest of the series.


Thank you,
Nicolas

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

Why? Why is this damn thing exported in the first place?

The moment we decide to change an MSR name or even remove it from that
file, we break userspace. And what for, because userspace is using some
arbitrary header file which was meant to be for the kernel solely.

NAKed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

Why? Why is this damn thing exported in the first place?

The moment we decide to change an MSR name or even remove it from that
file, we break userspace. And what for, because userspace is using some
arbitrary header file which was meant to be for the kernel solely.

NAKed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/x86/include/asm/msr-index.h  | 698 --
 arch/x86/include/uapi/asm/msr-index.h | 698 ++
 2 files changed, 698 insertions(+), 698 deletions(-)
 delete mode 100644 arch/x86/include/asm/msr-index.h
 create mode 100644 arch/x86/include/uapi/asm/msr-index.h

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
deleted file mode 100644
index 710273c617b8..
--- a/arch/x86/include/asm/msr-index.h
+++ /dev/null
@@ -1,698 +0,0 @@
-#ifndef _ASM_X86_MSR_INDEX_H
-#define _ASM_X86_MSR_INDEX_H
-
-/*
- * CPU model specific register (MSR) numbers.
- *
- * Do not add new entries to this file unless the definitions are shared
- * between multiple compilation units.
- */
-
-/* x86-64 specific MSRs */
-#define MSR_EFER   0xc080 /* extended feature register */
-#define MSR_STAR   0xc081 /* legacy mode SYSCALL target */
-#define MSR_LSTAR  0xc082 /* long mode SYSCALL target */
-#define MSR_CSTAR  0xc083 /* compat mode SYSCALL target */
-#define MSR_SYSCALL_MASK   0xc084 /* EFLAGS mask for syscall */
-#define MSR_FS_BASE0xc100 /* 64bit FS base */
-#define MSR_GS_BASE0xc101 /* 64bit GS base */
-#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */
-#define MSR_TSC_AUX0xc103 /* Auxiliary TSC */
-
-/* EFER bits: */
-#define _EFER_SCE  0  /* SYSCALL/SYSRET */
-#define _EFER_LME  8  /* Long mode enable */
-#define _EFER_LMA  10 /* Long mode active (read-only) */
-#define _EFER_NX   11 /* No execute enable */
-#define _EFER_SVME 12 /* Enable virtualization */
-#define _EFER_LMSLE13 /* Long Mode Segment Limit Enable */
-#define _EFER_FFXSR14 /* Enable Fast FXSAVE/FXRSTOR */
-
-#define EFER_SCE   (1<<_EFER_SCE)
-#define EFER_LME   (1<<_EFER_LME)
-#define EFER_LMA   (1<<_EFER_LMA)
-#define EFER_NX(1<<_EFER_NX)
-#define EFER_SVME  (1<<_EFER_SVME)
-#define EFER_LMSLE (1<<_EFER_LMSLE)
-#define EFER_FFXSR (1<<_EFER_FFXSR)
-
-/* Intel MSRs. Some also available on other CPUs */
-
-#define MSR_PPIN_CTL   0x004e
-#define MSR_PPIN   0x004f
-
-#define MSR_IA32_PERFCTR0  0x00c1
-#define MSR_IA32_PERFCTR1  0x00c2
-#define MSR_FSB_FREQ   0x00cd
-#define MSR_PLATFORM_INFO  0x00ce
-
-#define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2
-#define NHM_C3_AUTO_DEMOTE (1UL << 25)
-#define NHM_C1_AUTO_DEMOTE (1UL << 26)
-#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
-#define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
-
-#define MSR_MTRRcap0x00fe
-#define MSR_IA32_BBL_CR_CTL0x0119
-#define MSR_IA32_BBL_CR_CTL3   0x011e
-
-#define MSR_IA32_SYSENTER_CS   0x0174
-#define MSR_IA32_SYSENTER_ESP  0x0175
-#define MSR_IA32_SYSENTER_EIP  0x0176
-
-#define MSR_IA32_MCG_CAP   0x0179
-#define MSR_IA32_MCG_STATUS0x017a
-#define MSR_IA32_MCG_CTL   0x017b
-#define MSR_IA32_MCG_EXT_CTL   0x04d0
-
-#define MSR_OFFCORE_RSP_0  0x01a6
-#define MSR_OFFCORE_RSP_1  0x01a7
-#define MSR_TURBO_RATIO_LIMIT  0x01ad
-#define MSR_TURBO_RATIO_LIMIT1 0x01ae
-#define MSR_TURBO_RATIO_LIMIT2 0x01af
-
-#define MSR_LBR_SELECT 0x01c8
-#define MSR_LBR_TOS0x01c9
-#define MSR_LBR_NHM_FROM   0x0680
-#define MSR_LBR_NHM_TO 0x06c0
-#define MSR_LBR_CORE_FROM  0x0040
-#define MSR_LBR_CORE_TO0x0060
-
-#define MSR_LBR_INFO_0 0x0dc0 /* ... 0xddf for _31 */
-#define LBR_INFO_MISPRED   BIT_ULL(63)
-#define LBR_INFO_IN_TX BIT_ULL(62)
-#define LBR_INFO_ABORT BIT_ULL(61)
-#define LBR_INFO_CYCLES0x
-
-#define MSR_IA32_PEBS_ENABLE   0x03f1
-#define MSR_IA32_DS_AREA   0x0600
-#define MSR_IA32_PERF_CAPABILITIES 0x0345
-#define MSR_PEBS_LD_LAT_THRESHOLD  0x03f6
-
-#define MSR_IA32_RTIT_CTL  0x0570
-#define MSR_IA32_RTIT_STATUS   0x0571
-#define MSR_IA32_RTIT_ADDR0_A  0x0580
-#define MSR_IA32_RTIT_ADDR0_B  0x0581
-#define MSR_IA32_RTIT_ADDR1_A  0x0582
-#define MSR_IA32_RTIT_ADDR1_B  0x0583
-#define MSR_IA32_RTIT_ADDR2_A  0x0584
-#define 

[PATCH v4 3/7] x86: put msr-index.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/x86/include/asm/msr-index.h  | 698 --
 arch/x86/include/uapi/asm/msr-index.h | 698 ++
 2 files changed, 698 insertions(+), 698 deletions(-)
 delete mode 100644 arch/x86/include/asm/msr-index.h
 create mode 100644 arch/x86/include/uapi/asm/msr-index.h

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
deleted file mode 100644
index 710273c617b8..
--- a/arch/x86/include/asm/msr-index.h
+++ /dev/null
@@ -1,698 +0,0 @@
-#ifndef _ASM_X86_MSR_INDEX_H
-#define _ASM_X86_MSR_INDEX_H
-
-/*
- * CPU model specific register (MSR) numbers.
- *
- * Do not add new entries to this file unless the definitions are shared
- * between multiple compilation units.
- */
-
-/* x86-64 specific MSRs */
-#define MSR_EFER   0xc080 /* extended feature register */
-#define MSR_STAR   0xc081 /* legacy mode SYSCALL target */
-#define MSR_LSTAR  0xc082 /* long mode SYSCALL target */
-#define MSR_CSTAR  0xc083 /* compat mode SYSCALL target */
-#define MSR_SYSCALL_MASK   0xc084 /* EFLAGS mask for syscall */
-#define MSR_FS_BASE0xc100 /* 64bit FS base */
-#define MSR_GS_BASE0xc101 /* 64bit GS base */
-#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */
-#define MSR_TSC_AUX0xc103 /* Auxiliary TSC */
-
-/* EFER bits: */
-#define _EFER_SCE  0  /* SYSCALL/SYSRET */
-#define _EFER_LME  8  /* Long mode enable */
-#define _EFER_LMA  10 /* Long mode active (read-only) */
-#define _EFER_NX   11 /* No execute enable */
-#define _EFER_SVME 12 /* Enable virtualization */
-#define _EFER_LMSLE13 /* Long Mode Segment Limit Enable */
-#define _EFER_FFXSR14 /* Enable Fast FXSAVE/FXRSTOR */
-
-#define EFER_SCE   (1<<_EFER_SCE)
-#define EFER_LME   (1<<_EFER_LME)
-#define EFER_LMA   (1<<_EFER_LMA)
-#define EFER_NX(1<<_EFER_NX)
-#define EFER_SVME  (1<<_EFER_SVME)
-#define EFER_LMSLE (1<<_EFER_LMSLE)
-#define EFER_FFXSR (1<<_EFER_FFXSR)
-
-/* Intel MSRs. Some also available on other CPUs */
-
-#define MSR_PPIN_CTL   0x004e
-#define MSR_PPIN   0x004f
-
-#define MSR_IA32_PERFCTR0  0x00c1
-#define MSR_IA32_PERFCTR1  0x00c2
-#define MSR_FSB_FREQ   0x00cd
-#define MSR_PLATFORM_INFO  0x00ce
-
-#define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2
-#define NHM_C3_AUTO_DEMOTE (1UL << 25)
-#define NHM_C1_AUTO_DEMOTE (1UL << 26)
-#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
-#define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
-
-#define MSR_MTRRcap0x00fe
-#define MSR_IA32_BBL_CR_CTL0x0119
-#define MSR_IA32_BBL_CR_CTL3   0x011e
-
-#define MSR_IA32_SYSENTER_CS   0x0174
-#define MSR_IA32_SYSENTER_ESP  0x0175
-#define MSR_IA32_SYSENTER_EIP  0x0176
-
-#define MSR_IA32_MCG_CAP   0x0179
-#define MSR_IA32_MCG_STATUS0x017a
-#define MSR_IA32_MCG_CTL   0x017b
-#define MSR_IA32_MCG_EXT_CTL   0x04d0
-
-#define MSR_OFFCORE_RSP_0  0x01a6
-#define MSR_OFFCORE_RSP_1  0x01a7
-#define MSR_TURBO_RATIO_LIMIT  0x01ad
-#define MSR_TURBO_RATIO_LIMIT1 0x01ae
-#define MSR_TURBO_RATIO_LIMIT2 0x01af
-
-#define MSR_LBR_SELECT 0x01c8
-#define MSR_LBR_TOS0x01c9
-#define MSR_LBR_NHM_FROM   0x0680
-#define MSR_LBR_NHM_TO 0x06c0
-#define MSR_LBR_CORE_FROM  0x0040
-#define MSR_LBR_CORE_TO0x0060
-
-#define MSR_LBR_INFO_0 0x0dc0 /* ... 0xddf for _31 */
-#define LBR_INFO_MISPRED   BIT_ULL(63)
-#define LBR_INFO_IN_TX BIT_ULL(62)
-#define LBR_INFO_ABORT BIT_ULL(61)
-#define LBR_INFO_CYCLES0x
-
-#define MSR_IA32_PEBS_ENABLE   0x03f1
-#define MSR_IA32_DS_AREA   0x0600
-#define MSR_IA32_PERF_CAPABILITIES 0x0345
-#define MSR_PEBS_LD_LAT_THRESHOLD  0x03f6
-
-#define MSR_IA32_RTIT_CTL  0x0570
-#define MSR_IA32_RTIT_STATUS   0x0571
-#define MSR_IA32_RTIT_ADDR0_A  0x0580
-#define MSR_IA32_RTIT_ADDR0_B  0x0581
-#define MSR_IA32_RTIT_ADDR1_A  0x0582
-#define MSR_IA32_RTIT_ADDR1_B  0x0583
-#define MSR_IA32_RTIT_ADDR2_A  0x0584
-#define MSR_IA32_RTIT_ADDR2_B