* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) [not found] ` <e9286016-66ae-9505-ea52-834527cdae27@infradead.org> @ 2020-03-25 15:32 ` Sean Christopherson 2020-03-25 15:46 ` Paolo Bonzini 1 sibling, 0 replies; 8+ messages in thread From: Sean Christopherson @ 2020-03-25 15:32 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, KVM, Paolo Bonzini, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On Wed, Mar 25, 2020 at 08:30:00AM -0700, Randy Dunlap wrote: > On 3/25/20 1:53 AM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20200324: > > > > > on i386 randconfig build: > and gcc 7.5.0: > > 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h > function __cpuid_entry_get_reg(), for the default: case. I'll take a gander at this. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) [not found] ` <e9286016-66ae-9505-ea52-834527cdae27@infradead.org> 2020-03-25 15:32 ` linux-next: Tree for Mar 25 (arch/x86/kvm/) Sean Christopherson @ 2020-03-25 15:46 ` Paolo Bonzini 2020-03-25 15:57 ` Randy Dunlap 1 sibling, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2020-03-25 15:46 UTC (permalink / raw) To: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, KVM, Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On 25/03/20 16:30, Randy Dunlap wrote: > 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h > function __cpuid_entry_get_reg(), for the default: case. > > > CC arch/x86/kvm/cpuid.o > In file included from ../include/linux/export.h:43:0, > from ../include/linux/linkage.h:7, > from ../include/linux/preempt.h:10, > from ../include/linux/hardirq.h:5, > from ../include/linux/kvm_host.h:7, > from ../arch/x86/kvm/cpuid.c:12: > In function ‘__cpuid_entry_get_reg’, > inlined from ‘kvm_cpu_cap_mask’ at ../arch/x86/kvm/cpuid.c:272:25, > inlined from ‘kvm_set_cpu_caps’ at ../arch/x86/kvm/cpuid.c:292:2: > ../include/linux/compiler.h:394:38: error: call to ‘__compiletime_assert_114’ declared with attribute error: BUILD_BUG failed > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > ../include/linux/compiler.h:375:4: note: in definition of macro ‘__compiletime_assert’ > prefix ## suffix(); \ > ^~~~~~ > ../include/linux/compiler.h:394:2: note: in expansion of macro ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^~~~~~~~~~~~~~~~~~~ > ../include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^~~~~~~~~~~~~~~~~~ > ../include/linux/build_bug.h:59:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ > #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") > ^~~~~~~~~~~~~~~~ > ../arch/x86/kvm/cpuid.h:114:3: note: in expansion of macro ‘BUILD_BUG’ > BUILD_BUG(); > ^~~~~~~~~ > Looks like the compiler is not smart enough to figure out the constant expressions in BUILD_BUG. I think we need to do something like this: diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index 23b4cd1ad986..8f711b0cdec0 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -40,6 +40,7 @@ struct cpuid_reg { int reg; }; +/* Update reverse_cpuid_check as well when adding an entry. */ static const struct cpuid_reg reverse_cpuid[] = { [CPUID_1_EDX] = { 1, 0, CPUID_EDX}, [CPUID_8000_0001_EDX] = {0x80000001, 0, CPUID_EDX}, @@ -68,12 +69,21 @@ static const struct cpuid_reg reverse_cpuid[] = { */ static __always_inline void reverse_cpuid_check(unsigned int x86_leaf) { - BUILD_BUG_ON(x86_leaf == CPUID_LNX_1); - BUILD_BUG_ON(x86_leaf == CPUID_LNX_2); - BUILD_BUG_ON(x86_leaf == CPUID_LNX_3); - BUILD_BUG_ON(x86_leaf == CPUID_LNX_4); - BUILD_BUG_ON(x86_leaf >= ARRAY_SIZE(reverse_cpuid)); - BUILD_BUG_ON(reverse_cpuid[x86_leaf].function == 0); + BUILD_BUG_ON(x86_leaf != CPUID_1_EDX && + x86_leaf != CPUID_8000_0001_EDX && + x86_leaf != CPUID_8086_0001_EDX && + x86_leaf != CPUID_1_ECX && + x86_leaf != CPUID_C000_0001_EDX && + x86_leaf != CPUID_8000_0001_ECX && + x86_leaf != CPUID_7_0_EBX && + x86_leaf != CPUID_D_1_EAX && + x86_leaf != CPUID_8000_0008_EBX && + x86_leaf != CPUID_6_EAX && + x86_leaf != CPUID_8000_000A_EDX && + x86_leaf != CPUID_7_ECX && + x86_leaf != CPUID_8000_0007_EBX && + x86_leaf != CPUID_7_EDX && + x86_leaf != CPUID_7_1_EAX); } /* Randy, can you test it with your compiler? Thanks, Paolo ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 15:46 ` Paolo Bonzini @ 2020-03-25 15:57 ` Randy Dunlap 2020-03-25 16:08 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Randy Dunlap @ 2020-03-25 15:57 UTC (permalink / raw) To: Paolo Bonzini, Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, KVM, Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On 3/25/20 8:46 AM, Paolo Bonzini wrote: > On 25/03/20 16:30, Randy Dunlap wrote: >> 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h >> function __cpuid_entry_get_reg(), for the default: case. >> >> >> CC arch/x86/kvm/cpuid.o >> In file included from ../include/linux/export.h:43:0, >> from ../include/linux/linkage.h:7, >> from ../include/linux/preempt.h:10, >> from ../include/linux/hardirq.h:5, >> from ../include/linux/kvm_host.h:7, >> from ../arch/x86/kvm/cpuid.c:12: >> In function ‘__cpuid_entry_get_reg’, >> inlined from ‘kvm_cpu_cap_mask’ at ../arch/x86/kvm/cpuid.c:272:25, >> inlined from ‘kvm_set_cpu_caps’ at ../arch/x86/kvm/cpuid.c:292:2: >> ../include/linux/compiler.h:394:38: error: call to ‘__compiletime_assert_114’ declared with attribute error: BUILD_BUG failed >> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) >> ^ >> ../include/linux/compiler.h:375:4: note: in definition of macro ‘__compiletime_assert’ >> prefix ## suffix(); \ >> ^~~~~~ >> ../include/linux/compiler.h:394:2: note: in expansion of macro ‘_compiletime_assert’ >> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) >> ^~~~~~~~~~~~~~~~~~~ >> ../include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ >> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) >> ^~~~~~~~~~~~~~~~~~ >> ../include/linux/build_bug.h:59:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ >> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") >> ^~~~~~~~~~~~~~~~ >> ../arch/x86/kvm/cpuid.h:114:3: note: in expansion of macro ‘BUILD_BUG’ >> BUILD_BUG(); >> ^~~~~~~~~ >> > > Looks like the compiler is not smart enough to figure out the constant > expressions in BUILD_BUG. I think we need to do something like this: > > diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h > index 23b4cd1ad986..8f711b0cdec0 100644 > --- a/arch/x86/kvm/cpuid.h > +++ b/arch/x86/kvm/cpuid.h > @@ -40,6 +40,7 @@ struct cpuid_reg { > int reg; > }; > > +/* Update reverse_cpuid_check as well when adding an entry. */ > static const struct cpuid_reg reverse_cpuid[] = { > [CPUID_1_EDX] = { 1, 0, CPUID_EDX}, > [CPUID_8000_0001_EDX] = {0x80000001, 0, CPUID_EDX}, > @@ -68,12 +69,21 @@ static const struct cpuid_reg reverse_cpuid[] = { > */ > static __always_inline void reverse_cpuid_check(unsigned int x86_leaf) > { > - BUILD_BUG_ON(x86_leaf == CPUID_LNX_1); > - BUILD_BUG_ON(x86_leaf == CPUID_LNX_2); > - BUILD_BUG_ON(x86_leaf == CPUID_LNX_3); > - BUILD_BUG_ON(x86_leaf == CPUID_LNX_4); > - BUILD_BUG_ON(x86_leaf >= ARRAY_SIZE(reverse_cpuid)); > - BUILD_BUG_ON(reverse_cpuid[x86_leaf].function == 0); > + BUILD_BUG_ON(x86_leaf != CPUID_1_EDX && > + x86_leaf != CPUID_8000_0001_EDX && > + x86_leaf != CPUID_8086_0001_EDX && > + x86_leaf != CPUID_1_ECX && > + x86_leaf != CPUID_C000_0001_EDX && > + x86_leaf != CPUID_8000_0001_ECX && > + x86_leaf != CPUID_7_0_EBX && > + x86_leaf != CPUID_D_1_EAX && > + x86_leaf != CPUID_8000_0008_EBX && > + x86_leaf != CPUID_6_EAX && > + x86_leaf != CPUID_8000_000A_EDX && > + x86_leaf != CPUID_7_ECX && > + x86_leaf != CPUID_8000_0007_EBX && > + x86_leaf != CPUID_7_EDX && > + x86_leaf != CPUID_7_1_EAX); > } > > /* > > Randy, can you test it with your compiler? Nope, no help. That's the wrong location. Need a patch for this: >> 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h >> function __cpuid_entry_get_reg(), for the default: case. -- ~Randy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 15:57 ` Randy Dunlap @ 2020-03-25 16:08 ` Paolo Bonzini 2020-03-25 16:14 ` Sean Christopherson 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2020-03-25 16:08 UTC (permalink / raw) To: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, KVM, Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On 25/03/20 16:57, Randy Dunlap wrote: >> Randy, can you test it with your compiler? > Nope, no help. That's the wrong location. > Need a patch for this: >>> 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h >>> function __cpuid_entry_get_reg(), for the default: case. Doh, right. I think the only solution for that one is to degrade it to WARN_ON(1). Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 16:08 ` Paolo Bonzini @ 2020-03-25 16:14 ` Sean Christopherson 2020-03-25 16:26 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Sean Christopherson @ 2020-03-25 16:14 UTC (permalink / raw) To: Paolo Bonzini Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, KVM, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On Wed, Mar 25, 2020 at 05:08:03PM +0100, Paolo Bonzini wrote: > On 25/03/20 16:57, Randy Dunlap wrote: > >> Randy, can you test it with your compiler? > > Nope, no help. That's the wrong location. > > Need a patch for this: > >>> 24 (only showing one of them here) BUILD_BUG() errors in arch/x86/kvm/cpuid.h > >>> function __cpuid_entry_get_reg(), for the default: case. > > Doh, right. I think the only solution for that one is to degrade it to > WARN_ON(1). I reproduced the error, give me a bit to play with the code to see if the BUILD_BUG can be preserved. I'm curious as to why kvm_cpu_cap_mask() is special, and why it only fails with this config. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 16:14 ` Sean Christopherson @ 2020-03-25 16:26 ` Paolo Bonzini 2020-03-25 16:46 ` Sean Christopherson 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2020-03-25 16:26 UTC (permalink / raw) To: Sean Christopherson Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, KVM, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On 25/03/20 17:14, Sean Christopherson wrote: >> Doh, right. I think the only solution for that one is to degrade it to >> WARN_ON(1). > I reproduced the error, give me a bit to play with the code to see if the > BUILD_BUG can be preserved. I'm curious as to why kvm_cpu_cap_mask() is > special, and why it only fails with this config. > I could not reproduce it, but I would not be surprised if there are other configurations where the compiler cannot constant-propagate from the reverse_cpuid struct into __cpuid_entry_get_reg. Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 16:26 ` Paolo Bonzini @ 2020-03-25 16:46 ` Sean Christopherson 2020-03-25 18:47 ` Sean Christopherson 0 siblings, 1 reply; 8+ messages in thread From: Sean Christopherson @ 2020-03-25 16:46 UTC (permalink / raw) To: Paolo Bonzini Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, KVM, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On Wed, Mar 25, 2020 at 05:26:20PM +0100, Paolo Bonzini wrote: > On 25/03/20 17:14, Sean Christopherson wrote: > >> Doh, right. I think the only solution for that one is to degrade it to > >> WARN_ON(1). > > I reproduced the error, give me a bit to play with the code to see if the > > BUILD_BUG can be preserved. I'm curious as to why kvm_cpu_cap_mask() is > > special, and why it only fails with this config. > > > > I could not reproduce it, but I would not be surprised if there are > other configurations where the compiler cannot constant-propagate from > the reverse_cpuid struct into __cpuid_entry_get_reg. The error is related to UBSAN. There is at least one legitimate (but benign) underlying issue. I'm chasing down a second instance of the BUILD_BUG. Assuming all issues can be fixed, I think it'd make sense to keep the BUILD_BUG, especially if it's teasing out actual weirdness, even if the weirdness is benign. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: Tree for Mar 25 (arch/x86/kvm/) 2020-03-25 16:46 ` Sean Christopherson @ 2020-03-25 18:47 ` Sean Christopherson 0 siblings, 0 replies; 8+ messages in thread From: Sean Christopherson @ 2020-03-25 18:47 UTC (permalink / raw) To: Paolo Bonzini Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, KVM, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel On Wed, Mar 25, 2020 at 09:46:06AM -0700, Sean Christopherson wrote: > On Wed, Mar 25, 2020 at 05:26:20PM +0100, Paolo Bonzini wrote: > > On 25/03/20 17:14, Sean Christopherson wrote: > > >> Doh, right. I think the only solution for that one is to degrade it to > > >> WARN_ON(1). > > > I reproduced the error, give me a bit to play with the code to see if the > > > BUILD_BUG can be preserved. I'm curious as to why kvm_cpu_cap_mask() is > > > special, and why it only fails with this config. > > > > > > > I could not reproduce it, but I would not be surprised if there are > > other configurations where the compiler cannot constant-propagate from > > the reverse_cpuid struct into __cpuid_entry_get_reg. > > The error is related to UBSAN. There is at least one legitimate (but benign) > underlying issue. I'm chasing down a second instance of the BUILD_BUG. Argh, red herring. There is no underlying issue other than gcc tripping up when -fsanitize=alignment is enabled by UBSAN. Good news is that the build error can be fixed without resorting to a hack. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-03-25 18:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200325195350.7300fee9@canb.auug.org.au>
[not found] ` <e9286016-66ae-9505-ea52-834527cdae27@infradead.org>
2020-03-25 15:32 ` linux-next: Tree for Mar 25 (arch/x86/kvm/) Sean Christopherson
2020-03-25 15:46 ` Paolo Bonzini
2020-03-25 15:57 ` Randy Dunlap
2020-03-25 16:08 ` Paolo Bonzini
2020-03-25 16:14 ` Sean Christopherson
2020-03-25 16:26 ` Paolo Bonzini
2020-03-25 16:46 ` Sean Christopherson
2020-03-25 18:47 ` Sean Christopherson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).