* [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) @ 2020-03-01 19:03 Paolo Bonzini 2020-03-01 21:33 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Paolo Bonzini @ 2020-03-01 19:03 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel, kvm Linus, The following changes since commit a93236fcbe1d0248461b29c0f87cb0b510c94e6f: KVM: s390: rstify new ioctls in api.rst (2020-02-24 19:28:40 +0100) are available in the git repository at: https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to 86f7e90ce840aa1db407d3ea6e9b3a52b2ce923c: KVM: VMX: check descriptor table exits on instruction emulation (2020-03-01 19:26:31 +0100) ---------------------------------------------------------------- More bugfixes, including a few remaining "make W=1" issues such as too large frame sizes on some configurations. On the ARM side, the compiler was messing up shadow stacks between EL1 and EL2 code, which is easily fixed with __always_inline. ---------------------------------------------------------------- Christian Borntraeger (1): KVM: let declaration of kvm_get_running_vcpus match implementation Erwan Velu (1): kvm: x86: Limit the number of "kvm: disabled by bios" messages James Morse (3): KVM: arm64: Ask the compiler to __always_inline functions used at HYP KVM: arm64: Define our own swab32() to avoid a uapi static inline arm64: Ask the compiler to __always_inline functions used by KVM at HYP Jeremy Cline (1): KVM: arm/arm64: Fix up includes for trace.h Mark Rutland (1): kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() Oliver Upton (1): KVM: VMX: check descriptor table exits on instruction emulation Paolo Bonzini (4): KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter KVM: allow disabling -Werror KVM: x86: avoid useless copy of cpufreq policy Merge tag 'kvmarm-fixes-5.6-1' of git://git.kernel.org/.../kvmarm/kvmarm into HEAD Valdis Kletnieks (1): KVM: x86: allow compiling as non-module with W=1 Wanpeng Li (2): KVM: Introduce pv check helpers KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis arch/arm/include/asm/kvm_host.h | 3 -- arch/arm64/include/asm/arch_gicv3.h | 2 +- arch/arm64/include/asm/cache.h | 2 +- arch/arm64/include/asm/cacheflush.h | 2 +- arch/arm64/include/asm/cpufeature.h | 10 ++--- arch/arm64/include/asm/io.h | 4 +- arch/arm64/include/asm/kvm_emulate.h | 48 +++++++++++------------ arch/arm64/include/asm/kvm_host.h | 32 ---------------- arch/arm64/include/asm/kvm_hyp.h | 7 ++++ arch/arm64/include/asm/kvm_mmu.h | 3 +- arch/arm64/include/asm/virt.h | 2 +- arch/arm64/kvm/hyp/switch.c | 39 ++++++++++++++++++- arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 +- arch/x86/kernel/kvm.c | 65 +++++++++++++++++++++----------- arch/x86/kvm/Kconfig | 13 +++++++ arch/x86/kvm/Makefile | 2 +- arch/x86/kvm/svm.c | 5 ++- arch/x86/kvm/vmx/vmx.c | 17 +++++++++ arch/x86/kvm/x86.c | 14 +++---- include/linux/kvm_host.h | 2 +- virt/kvm/arm/arm.c | 2 - virt/kvm/arm/trace.h | 1 + 22 files changed, 171 insertions(+), 108 deletions(-) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 19:03 [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) Paolo Bonzini @ 2020-03-01 21:33 ` Linus Torvalds 2020-03-01 23:04 ` Paolo Bonzini ` (2 more replies) 2020-03-01 22:45 ` pr-tracker-bot 2020-03-02 5:38 ` Naresh Kamboju 2 siblings, 3 replies; 10+ messages in thread From: Linus Torvalds @ 2020-03-01 21:33 UTC (permalink / raw) To: Paolo Bonzini, Michael Ellerman Cc: Linux Kernel Mailing List, KVM list, linuxppc-dev On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > Paolo Bonzini (4): > KVM: allow disabling -Werror Honestly, this is just badly done. You've basically made it enable -Werror only for very random configurations - and apparently the one you test. Doing things like COMPILE_TEST disables it, but so does not having EXPERT enabled. So it looks entirely ad-hoc and makes very little sense. At least the "with KASAN, disable this" part makes sense, since that's a known source or warnings. But everything else looks very random. I've merged this, but I wonder why you couldn't just do what I suggested originally? Seriously, if you script your build tests, and don't even look at the results, then you might as well use make KCFLAGS=-Werror instead of having this kind of completely random option that has almost no logic to it at all. And if you depend entirely on random build infrastructure like the 0day bot etc, this likely _is_ going to break when it starts using a new gcc version, or when it starts testing using clang, or whatever. So then we end up with another odd random situation where now kvm (and only kvm) will fail those builds just because they are automated. Yes, as I said in that original thread, I'd love to do -Werror in general, at which point it wouldn't be some random ad-hoc kvm special case for some random option. But the "now it causes problems for random compiler versions" is a real issue again - but at least it wouldn't be a random kernel subsystem that happens to trigger it, it would be a _generic_ issue, and we'd have everybody involved when a compiler change introduces a new warning. I've pulled this for now, but I really think it's a horrible hack, and it's just done entirely wrong. Adding the powerpc people, since they have more history with their somewhat less hacky one. Except that one automatically gets disabled by "make allmodconfig" and friends, which is also kind of pointless. Michael, what tends to be the triggers for people using PPC_DISABLE_WERROR? Do you have reports for it? Could we have a _generic_ option that just gets enabled by default, except it gets disabled by _known_ issues (like KASAN). Being disabled for "make allmodconfig" is kind of against one of the _points_ of "the build should be warning-free". Linus ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 21:33 ` Linus Torvalds @ 2020-03-01 23:04 ` Paolo Bonzini 2020-03-02 5:10 ` Nathan Chancellor 2020-03-02 10:51 ` Michael Ellerman 2 siblings, 0 replies; 10+ messages in thread From: Paolo Bonzini @ 2020-03-01 23:04 UTC (permalink / raw) To: Linus Torvalds, Michael Ellerman Cc: Linux Kernel Mailing List, KVM list, linuxppc-dev On 01/03/20 22:33, Linus Torvalds wrote: > On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> Paolo Bonzini (4): >> KVM: allow disabling -Werror > > Honestly, this is just badly done. > > You've basically made it enable -Werror only for very random > configurations - and apparently the one you test. > Doing things like COMPILE_TEST disables it, but so does not having > EXPERT enabled. Yes, I took this from the i915 Kconfig. It's temporary, in 5.7 I am planning to get it to just !KASAN, but for 5.6 I wanted to avoid more breakage so I added the other restrictions. The difference between x86-64 and i386 is really just the frame size warnings, which Christoph triggered because of a higher CONFIG_NR_CPUS. (BTW, perhaps it makes sense for Sparse to have something like __nostack for structs that contain potentially large arrays). > I've merged this, but I wonder why you couldn't just do what I > suggested originally? Seriously, if you script your build tests, > and don't even look at the results, then you might as well use > > make KCFLAGS=-Werror I did that and I'm also adding W=1; and I threw in a smaller than default frame size warning option too because I don't want cpumasks on the stack anyway. However, that wouldn't help contributors. I'm okay if I get W=1 or frame size warnings from patches from other contributors, but I think it's a disservice to them that they have to set KCFLAGS in order to avoid warnings. > the "now it causes problems for > random compiler versions" is a real issue again - but at least it > wouldn't be a random kernel subsystem that happens to trigger it, it > would be a _generic_ issue, and we'd have everybody involved when a > compiler change introduces a new warning. Yes, and GCC prereleases are tested with Linux, for example by doing full Rawhide rebuilds. If we started using -Werror by default (including allyesconfig), they would probably report warnings early. Same for clang. I hope that Linux can have -Werror everywhere, or at least a CONFIG_WERROR option that does it even if it defaults to n for a release or more. But I don't think we can get there without first seeing what issues pop up in a few subsystems or arches---even before considering new compilers---so I decided I would just try. Paolo > Adding the powerpc people, since they have more history with their > somewhat less hacky one. Except that one automatically gets disabled > by "make allmodconfig" and friends, which is also kind of pointless. > Michael, what tends to be the triggers for people using > PPC_DISABLE_WERROR? Do you have reports for it? Could we have a > _generic_ option that just gets enabled by default, except it gets > disabled by _known_ issues (like KASAN). > > Being disabled for "make allmodconfig" is kind of against one of the > _points_ of "the build should be warning-free". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 21:33 ` Linus Torvalds 2020-03-01 23:04 ` Paolo Bonzini @ 2020-03-02 5:10 ` Nathan Chancellor 2020-03-02 10:51 ` Michael Ellerman 2 siblings, 0 replies; 10+ messages in thread From: Nathan Chancellor @ 2020-03-02 5:10 UTC (permalink / raw) To: Linus Torvalds Cc: Paolo Bonzini, Michael Ellerman, linux-kernel, clang-built-linux + CBL mailing list, my two cents below. On Sun, Mar 01, 2020 at 03:33:48PM -0600, Linus Torvalds wrote: > On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > Paolo Bonzini (4): > > KVM: allow disabling -Werror > > Honestly, this is just badly done. > > You've basically made it enable -Werror only for very random > configurations - and apparently the one you test. > > Doing things like COMPILE_TEST disables it, but so does not having > EXPERT enabled. > > So it looks entirely ad-hoc and makes very little sense. At least the > "with KASAN, disable this" part makes sense, since that's a known > source or warnings. But everything else looks very random. > > I've merged this, but I wonder why you couldn't just do what I > suggested originally? > > Seriously, if you script your build tests, and don't even look at the > results, then you might as well use > > make KCFLAGS=-Werror > > instead of having this kind of completely random option that has > almost no logic to it at all. > > And if you depend entirely on random build infrastructure like the > 0day bot etc, this likely _is_ going to break when it starts using a > new gcc version, or when it starts testing using clang, or whatever. > So then we end up with another odd random situation where now kvm (and > only kvm) will fail those builds just because they are automated. Just FYI, 0day clang builds are live now. I have not seen anything from KVM yet but I do not know how many configurations are being tested and such: https://lore.kernel.org/lkml/CAKwvOdn9mpsjpAbVQbS0LC9iPtNrCZU+Pbh2Bt7kSXa4S8KQEg@mail.gmail.com/ > Yes, as I said in that original thread, I'd love to do -Werror in > general, at which point it wouldn't be some random ad-hoc kvm special > case for some random option. But the "now it causes problems for > random compiler versions" is a real issue again - but at least it > wouldn't be a random kernel subsystem that happens to trigger it, it > would be a _generic_ issue, and we'd have everybody involved when a > compiler change introduces a new warning. Indeed; our CI for clang builds is all done with the master versions of clang available from apt.llvm.org so we can catch issues as soon as possible and having -Werror would mean a potentially benign issue (like one we are currently dealing with where clang's -Wvoid-pointer-to-int-cast warns when casting to an enum where gcc does not: https://reviews.llvm.org/D72231#1878528) would cause our CI to go instantly red across the board and not catch other issues. I would say a CONFIG_CC_WERROR or something of that nature would not necessarily be a bad thing since we could just disable it for our CI (or have it be default disabled) but I think if someone cares about -Werror, they should just use the KCFLAGS trick at the point, since I would think that would be easier than maintaining a separate config option. > I've pulled this for now, but I really think it's a horrible hack, and > it's just done entirely wrong. > > Adding the powerpc people, since they have more history with their > somewhat less hacky one. Except that one automatically gets disabled > by "make allmodconfig" and friends, which is also kind of pointless. > > Michael, what tends to be the triggers for people using > PPC_DISABLE_WERROR? Do you have reports for it? Could we have a > _generic_ option that just gets enabled by default, except it gets > disabled by _known_ issues (like KASAN). > > Being disabled for "make allmodconfig" is kind of against one of the > _points_ of "the build should be warning-free". > > Linus FWIW, our clang powerpc builds were broken for 4 months because of arch/powerpc using -Werror: https://github.com/ClangBuiltLinux/linux/issues/625 We have infrastructure in place to carry out of tree patches if absolutely necessary, which we had to use for a while: https://github.com/ClangBuiltLinux/continuous-integration/commit/4d1b3c74bcb3ed0090073c9d9e6ae303425d4adc https://github.com/ClangBuiltLinux/continuous-integration/commit/0c3885049e2a6e28c72be13f5b05fb25ff79904b https://github.com/ClangBuiltLinux/continuous-integration/commit/533fcec33fdb8526333a6fd91d24534eeb96bed5 Even now, there is a warning in the RDMA subsystem that points to a very clear bug that has still not been merged into your tree: https://git.kernel.org/rdma/rdma/c/4ca501d6aaf21de31541deac35128bbea8427aa6 I am not blaming anyone for that, I get that every maintainer has their own test suite and pull request schedule but I believe that it shows the general apathy towards warning fixes from maintainers (at least, from the perspective of someone who sends a large amount of warning fixes). I would argue this should change before -Werror could even begin to be considered as a default option. Cheers, Nathan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 21:33 ` Linus Torvalds 2020-03-01 23:04 ` Paolo Bonzini 2020-03-02 5:10 ` Nathan Chancellor @ 2020-03-02 10:51 ` Michael Ellerman 2020-03-02 12:14 ` Segher Boessenkool 2 siblings, 1 reply; 10+ messages in thread From: Michael Ellerman @ 2020-03-02 10:51 UTC (permalink / raw) To: Linus Torvalds, Paolo Bonzini Cc: Linux Kernel Mailing List, KVM list, linuxppc-dev, Masahiro Yamada Linus Torvalds <torvalds@linux-foundation.org> writes: > On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> Paolo Bonzini (4): >> KVM: allow disabling -Werror > > Honestly, this is just badly done. > > You've basically made it enable -Werror only for very random > configurations - and apparently the one you test. > > Doing things like COMPILE_TEST disables it, but so does not having > EXPERT enabled. > > So it looks entirely ad-hoc and makes very little sense. At least the > "with KASAN, disable this" part makes sense, since that's a known > source or warnings. But everything else looks very random. > > I've merged this, but I wonder why you couldn't just do what I > suggested originally? > > Seriously, if you script your build tests, and don't even look at the > results, then you might as well use > > make KCFLAGS=-Werror > > instead of having this kind of completely random option that has > almost no logic to it at all. > > And if you depend entirely on random build infrastructure like the > 0day bot etc, this likely _is_ going to break when it starts using a > new gcc version, or when it starts testing using clang, or whatever. > So then we end up with another odd random situation where now kvm (and > only kvm) will fail those builds just because they are automated. > > Yes, as I said in that original thread, I'd love to do -Werror in > general, at which point it wouldn't be some random ad-hoc kvm special > case for some random option. But the "now it causes problems for > random compiler versions" is a real issue again - but at least it > wouldn't be a random kernel subsystem that happens to trigger it, it > would be a _generic_ issue, and we'd have everybody involved when a > compiler change introduces a new warning. > > I've pulled this for now, but I really think it's a horrible hack, and > it's just done entirely wrong. > > Adding the powerpc people, since they have more history with their > somewhat less hacky one. Except that one automatically gets disabled > by "make allmodconfig" and friends, which is also kind of pointless. > > Michael, what tends to be the triggers for people using > PPC_DISABLE_WERROR? Do you have reports for it? My memory is that we have had very few reports of it actually causing problems. But I don't have hard data to back that up. It has tripped up the Clang folks, but that's partly because they're building clang HEAD, and also because ~zero powerpc kernel developers are building regularly with clang. I'm trying to fix the latter ... The thing that makes me disable -Werror (enable PPC_DISABLE_WERROR) most often is bisecting back to before fixes for my current compiler were merged. For example with GCC 8 if you go back before ~4.18 you hit the warning fixed by bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()"). And then building with GCC head sometimes requires disabling -Werror because of some new warning, sometimes valid sometimes not. I think we could mostly avoid those problems by having the option only on by default for known compiler versions. eg: config WERROR bool "Build with -Werror" default CC_IS_GCC && (GCC_VERSION >= 70000 && GCC_VERSION <= 90000) And we could bump the upper version up once each new GCC version has had any problems ironed out. > Could we have a _generic_ option that just gets enabled by default, > except it gets disabled by _known_ issues (like KASAN). Right now I don't think we could have a generic option that's enabled by default, there's too many warnings floating around on minor arches and in odd configurations. But we could have a generic option that signifies the desire to build with -Werror where possible, and then each arch/subsystem/etc could use that config option to enable -Werror in stages. Then after a release or three we could change the option to globally enable -Werror and opt-out any areas that are still problematic. It's also possible to use -Wno-error to turn certain warnings back into warnings even when -Werror is set, so that's another way we could incrementally attack the problem. It'd also be nice if we could do: $ make WERROR=0 Or something similarly obvious to turn off the WERROR option. That way users don't even have to edit their .config manually, they just rerun make with WERROR=0 and it works. > Being disabled for "make allmodconfig" is kind of against one of the > _points_ of "the build should be warning-free". True, it was just the conservative choice to disable it for allmod/yes. We should probably revisit that these days. cheers ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-02 10:51 ` Michael Ellerman @ 2020-03-02 12:14 ` Segher Boessenkool 0 siblings, 0 replies; 10+ messages in thread From: Segher Boessenkool @ 2020-03-02 12:14 UTC (permalink / raw) To: Michael Ellerman Cc: Linus Torvalds, Paolo Bonzini, Masahiro Yamada, linuxppc-dev, Linux Kernel Mailing List, KVM list On Mon, Mar 02, 2020 at 09:51:44PM +1100, Michael Ellerman wrote: > Linus Torvalds <torvalds@linux-foundation.org> writes: > > Michael, what tends to be the triggers for people using > > PPC_DISABLE_WERROR? Do you have reports for it? > > My memory is that we have had very few reports of it actually causing > problems. But I don't have hard data to back that up. I build all archs with GCC trunk. It always breaks for me, with thousands of errors, which is why since many years I carry 21 lines of patch to thoroughly disable -Werror for the powerpc arch. It takes over a year from when a warning is added to the kernel taking care of it -- and of course, I build with the current development version of the compiler, so I get to see many misfiring warnings and other fallout as well. (Currently there are more than 100 warnings, this is way too many to consider attacking that as well). > It has tripped up the Clang folks, but that's partly because they're > building clang HEAD, and also because ~zero powerpc kernel developers > are building regularly with clang. I'm trying to fix the latter ... Is anyone building regularly with GCC HEAD? Power or any other arch? > And then building with GCC head sometimes requires disabling -Werror > because of some new warning, sometimes valid sometimes not. Yes. And never worth breaking the build for. -Werror is something you use if you do not trust your developers. Warnings are not errors. The compiler warns for things that heuristically look suspicious. And it errors for things that are wrong. Some warnings have many false positives, but are so useful (find many nasty problems, for example) that it is worth enabling them often. -Werror sabotages that, giving people an extra incentive to disable useful warnings. > I think we could mostly avoid those problems by having the option only > on by default for known compiler versions. Well, the kernel disables most useful warnings anyway, so that might even work, sure. > It'd also be nice if we could do: > > $ make WERROR=0 > > Or something similarly obvious to turn off the WERROR option. That way > users don't even have to edit their .config manually, they just rerun > make with WERROR=0 and it works. That would be nice, yes, that would help my situation as well. Segher ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 19:03 [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) Paolo Bonzini 2020-03-01 21:33 ` Linus Torvalds @ 2020-03-01 22:45 ` pr-tracker-bot 2020-03-02 5:38 ` Naresh Kamboju 2 siblings, 0 replies; 10+ messages in thread From: pr-tracker-bot @ 2020-03-01 22:45 UTC (permalink / raw) To: Paolo Bonzini; +Cc: torvalds, linux-kernel, kvm The pull request you sent on Sun, 1 Mar 2020 20:03:10 +0100: > https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f853ed90e2e49f4f6e585f995ffb25e093fe4df6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-01 19:03 [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) Paolo Bonzini 2020-03-01 21:33 ` Linus Torvalds 2020-03-01 22:45 ` pr-tracker-bot @ 2020-03-02 5:38 ` Naresh Kamboju 2020-03-02 7:21 ` Wanpeng Li 2 siblings, 1 reply; 10+ messages in thread From: Naresh Kamboju @ 2020-03-02 5:38 UTC (permalink / raw) To: Paolo Bonzini, kvm list Cc: Linus Torvalds, open list, lkft-triage, Anders Roxell, oupton, jmattson On Mon, 2 Mar 2020 at 00:33, Paolo Bonzini <pbonzini@redhat.com> wrote: > > Linus, > > The following changes since commit a93236fcbe1d0248461b29c0f87cb0b510c94e6f: > > KVM: s390: rstify new ioctls in api.rst (2020-02-24 19:28:40 +0100) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus > > for you to fetch changes up to 86f7e90ce840aa1db407d3ea6e9b3a52b2ce923c: > > KVM: VMX: check descriptor table exits on instruction emulation (2020-03-01 19:26:31 +0100) > > ---------------------------------------------------------------- > More bugfixes, including a few remaining "make W=1" issues such > as too large frame sizes on some configurations. On the > ARM side, the compiler was messing up shadow stacks between > EL1 and EL2 code, which is easily fixed with __always_inline. > > ---------------------------------------------------------------- > Christian Borntraeger (1): > KVM: let declaration of kvm_get_running_vcpus match implementation > > Erwan Velu (1): > kvm: x86: Limit the number of "kvm: disabled by bios" messages > > James Morse (3): > KVM: arm64: Ask the compiler to __always_inline functions used at HYP > KVM: arm64: Define our own swab32() to avoid a uapi static inline > arm64: Ask the compiler to __always_inline functions used by KVM at HYP > > Jeremy Cline (1): > KVM: arm/arm64: Fix up includes for trace.h > > Mark Rutland (1): > kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() > > Oliver Upton (1): > KVM: VMX: check descriptor table exits on instruction emulation > > Paolo Bonzini (4): > KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter > KVM: allow disabling -Werror > KVM: x86: avoid useless copy of cpufreq policy > Merge tag 'kvmarm-fixes-5.6-1' of git://git.kernel.org/.../kvmarm/kvmarm into HEAD > > Valdis Kletnieks (1): > KVM: x86: allow compiling as non-module with W=1 > > Wanpeng Li (2): > KVM: Introduce pv check helpers > KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis Kernel panic noticed on latest Linux mainline kernel. qemu_x86_64 boot failed due to kernel panic. Please investigate this problem. Meanwhile we will also investigate by using git bisect to identify bad patch. /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic \ -net nic,model=virtio,macaddr=DE:AD:BE:EF:66:05 -net tap \ -m 1024 -monitor none -kernel bzImage--5.5+git0+98d54f81e3-r0-intel-corei7-64-20200301225337-2502.bin \ --append "root=/dev/sda rootwait console=ttyS0,115200" \ -hda rpb-console-image-lkft-intel-corei7-64-20200301225337-2502.rootfs.ext4 \ -m 4096 -smp 4 -nographic \ -drive format=qcow2,file=lava-guest.qcow2,media=disk,if=virtio,id=lavatest [ 0.000000] Linux version 5.6.0-rc4 (oe-user@oe-host) (gcc version 7.3.0 (GCC)) #1 SMP Sun Mar 1 22:59:08 UTC 2020 <trim> [ 0.762542] kvm: no hardware support [ 0.763123] BUG: kernel NULL pointer dereference, address: 000000000000028c [ 0.763425] #PF: supervisor read access in kernel mode [ 0.763425] #PF: error_code(0x0000) - not-present page [ 0.763425] PGD 0 P4D 0 [ 0.763425] Oops: 0000 [#1] SMP NOPTI [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4 #1 [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f c1 43 [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) knlGS:0000000000000000 [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 [ 0.763425] Call Trace: [ 0.763425] cpufreq_cpu_put+0x15/0x20 [ 0.763425] kvm_arch_init+0x1f6/0x2b0 [ 0.763425] kvm_init+0x31/0x290 [ 0.763425] ? svm_check_processor_compat+0xd/0xd [ 0.763425] ? svm_check_processor_compat+0xd/0xd [ 0.763425] svm_init+0x21/0x23 [ 0.763425] do_one_initcall+0x61/0x2f0 [ 0.763425] ? rdinit_setup+0x30/0x30 [ 0.763425] ? rcu_read_lock_sched_held+0x4f/0x80 [ 0.763425] kernel_init_freeable+0x219/0x279 [ 0.763425] ? rest_init+0x250/0x250 [ 0.763425] kernel_init+0xe/0x110 [ 0.763425] ret_from_fork+0x27/0x50 [ 0.763425] Modules linked in: [ 0.763425] CR2: 000000000000028c [ 0.763425] ---[ end trace 239abf40c55c409b ]--- [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f c1 43 [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) knlGS:0000000000000000 [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 [ 0.763425] BUG: sleeping function called from invalid context at /usr/src/kernel/include/linux/percpu-rwsem.h:38 [ 0.763425] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 [ 0.763425] INFO: lockdep is turned off. [ 0.763425] irq event stamp: 696816 [ 0.763425] hardirqs last enabled at (696815): [<ffffffff98c929d1>] _raw_read_unlock_irqrestore+0x31/0x50 [ 0.763425] hardirqs last disabled at (696816): [<ffffffff97e01f3b>] trace_hardirqs_off_thunk+0x1a/0x1c [ 0.763425] softirqs last enabled at (696776): [<ffffffff99000338>] __do_softirq+0x338/0x43a [ 0.763425] softirqs last disabled at (696769): [<ffffffff97f045e8>] irq_exit+0xb8/0xc0 [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D 5.6.0-rc4 #1 [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 0.763425] Call Trace: [ 0.763425] dump_stack+0x7a/0xa5 [ 0.763425] ___might_sleep+0x163/0x250 [ 0.763425] __might_sleep+0x4a/0x80 [ 0.763425] exit_signals+0x33/0x2d0 [ 0.763425] do_exit+0xb6/0xcf0 [ 0.763425] ? kernel_init_freeable+0x219/0x279 [ 0.763425] ? rest_init+0x250/0x250 [ 0.763425] rewind_stack_do_exit+0x17/0x20 [ 0.763425] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git describe: v5.6-rc4 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-mainline/2502/config git log --online 98d54f81e36b (HEAD -> master, tag: v5.6-rc4, origin/master, origin/HEAD) Linux 5.6-rc4 e70869821a46 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 f853ed90e2e4 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 86f7e90ce840 KVM: VMX: check descriptor table exits on instruction emulation fb279f4e2386 Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux 37b0b6b8b99c ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() 38b17afb0ebb macintosh: therm_windtunnel: fix regression when instantiating devices 6c5d91124929 jbd2: fix data races at struct journal_head 7557c1b3f715 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi ref: https://lkft.validation.linaro.org/scheduler/job/1261774#L461 https://lkft.validation.linaro.org/scheduler/job/1261816#L477 -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-02 5:38 ` Naresh Kamboju @ 2020-03-02 7:21 ` Wanpeng Li 2020-03-02 11:31 ` Anders Roxell 0 siblings, 1 reply; 10+ messages in thread From: Wanpeng Li @ 2020-03-02 7:21 UTC (permalink / raw) To: Naresh Kamboju Cc: Paolo Bonzini, kvm list, Linus Torvalds, open list, lkft-triage, Anders Roxell, oupton, Jim Mattson On Mon, 2 Mar 2020 at 13:39, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > On Mon, 2 Mar 2020 at 00:33, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > Linus, > > > > The following changes since commit a93236fcbe1d0248461b29c0f87cb0b510c94e6f: > > > > KVM: s390: rstify new ioctls in api.rst (2020-02-24 19:28:40 +0100) > > > > are available in the git repository at: > > > > https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus > > > > for you to fetch changes up to 86f7e90ce840aa1db407d3ea6e9b3a52b2ce923c: > > > > KVM: VMX: check descriptor table exits on instruction emulation (2020-03-01 19:26:31 +0100) > > > > ---------------------------------------------------------------- > > More bugfixes, including a few remaining "make W=1" issues such > > as too large frame sizes on some configurations. On the > > ARM side, the compiler was messing up shadow stacks between > > EL1 and EL2 code, which is easily fixed with __always_inline. > > > > ---------------------------------------------------------------- > > Christian Borntraeger (1): > > KVM: let declaration of kvm_get_running_vcpus match implementation > > > > Erwan Velu (1): > > kvm: x86: Limit the number of "kvm: disabled by bios" messages > > > > James Morse (3): > > KVM: arm64: Ask the compiler to __always_inline functions used at HYP > > KVM: arm64: Define our own swab32() to avoid a uapi static inline > > arm64: Ask the compiler to __always_inline functions used by KVM at HYP > > > > Jeremy Cline (1): > > KVM: arm/arm64: Fix up includes for trace.h > > > > Mark Rutland (1): > > kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() > > > > Oliver Upton (1): > > KVM: VMX: check descriptor table exits on instruction emulation > > > > Paolo Bonzini (4): > > KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter > > KVM: allow disabling -Werror > > KVM: x86: avoid useless copy of cpufreq policy > > Merge tag 'kvmarm-fixes-5.6-1' of git://git.kernel.org/.../kvmarm/kvmarm into HEAD > > > > Valdis Kletnieks (1): > > KVM: x86: allow compiling as non-module with W=1 > > > > Wanpeng Li (2): > > KVM: Introduce pv check helpers > > KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis > > Kernel panic noticed on latest Linux mainline kernel. > qemu_x86_64 boot failed due to kernel panic. > Please investigate this problem. > Just give a quick shot. https://lkml.org/lkml/2020/3/2/78 > Meanwhile we will also investigate by using git bisect to identify bad patch. > > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic \ > -net nic,model=virtio,macaddr=DE:AD:BE:EF:66:05 -net tap \ > -m 1024 -monitor none -kernel > bzImage--5.5+git0+98d54f81e3-r0-intel-corei7-64-20200301225337-2502.bin > \ > --append "root=/dev/sda rootwait console=ttyS0,115200" \ > -hda rpb-console-image-lkft-intel-corei7-64-20200301225337-2502.rootfs.ext4 \ > -m 4096 -smp 4 -nographic \ > -drive format=qcow2,file=lava-guest.qcow2,media=disk,if=virtio,id=lavatest > > [ 0.000000] Linux version 5.6.0-rc4 (oe-user@oe-host) (gcc version > 7.3.0 (GCC)) #1 SMP Sun Mar 1 22:59:08 UTC 2020 > <trim> > [ 0.762542] kvm: no hardware support > [ 0.763123] BUG: kernel NULL pointer dereference, address: 000000000000028c > [ 0.763425] #PF: supervisor read access in kernel mode > [ 0.763425] #PF: error_code(0x0000) - not-present page > [ 0.763425] PGD 0 P4D 0 > [ 0.763425] Oops: 0000 [#1] SMP NOPTI > [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4 #1 > [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.12.0-1 04/01/2014 > [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 > [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e > 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 > 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f > c1 43 > [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 > [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 > [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 > [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 > [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be > [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) > knlGS:0000000000000000 > [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 > [ 0.763425] Call Trace: > [ 0.763425] cpufreq_cpu_put+0x15/0x20 > [ 0.763425] kvm_arch_init+0x1f6/0x2b0 > [ 0.763425] kvm_init+0x31/0x290 > [ 0.763425] ? svm_check_processor_compat+0xd/0xd > [ 0.763425] ? svm_check_processor_compat+0xd/0xd > [ 0.763425] svm_init+0x21/0x23 > [ 0.763425] do_one_initcall+0x61/0x2f0 > [ 0.763425] ? rdinit_setup+0x30/0x30 > [ 0.763425] ? rcu_read_lock_sched_held+0x4f/0x80 > [ 0.763425] kernel_init_freeable+0x219/0x279 > [ 0.763425] ? rest_init+0x250/0x250 > [ 0.763425] kernel_init+0xe/0x110 > [ 0.763425] ret_from_fork+0x27/0x50 > [ 0.763425] Modules linked in: > [ 0.763425] CR2: 000000000000028c > [ 0.763425] ---[ end trace 239abf40c55c409b ]--- > [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 > [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e > 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 > 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f > c1 43 > [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 > [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 > [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 > [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 > [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be > [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) > knlGS:0000000000000000 > [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 > [ 0.763425] BUG: sleeping function called from invalid context at > /usr/src/kernel/include/linux/percpu-rwsem.h:38 > [ 0.763425] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: > 1, name: swapper/0 > [ 0.763425] INFO: lockdep is turned off. > [ 0.763425] irq event stamp: 696816 > [ 0.763425] hardirqs last enabled at (696815): > [<ffffffff98c929d1>] _raw_read_unlock_irqrestore+0x31/0x50 > [ 0.763425] hardirqs last disabled at (696816): > [<ffffffff97e01f3b>] trace_hardirqs_off_thunk+0x1a/0x1c > [ 0.763425] softirqs last enabled at (696776): > [<ffffffff99000338>] __do_softirq+0x338/0x43a > [ 0.763425] softirqs last disabled at (696769): > [<ffffffff97f045e8>] irq_exit+0xb8/0xc0 > [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D > 5.6.0-rc4 #1 > [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.12.0-1 04/01/2014 > [ 0.763425] Call Trace: > [ 0.763425] dump_stack+0x7a/0xa5 > [ 0.763425] ___might_sleep+0x163/0x250 > [ 0.763425] __might_sleep+0x4a/0x80 > [ 0.763425] exit_signals+0x33/0x2d0 > [ 0.763425] do_exit+0xb6/0xcf0 > [ 0.763425] ? kernel_init_freeable+0x219/0x279 > [ 0.763425] ? rest_init+0x250/0x250 > [ 0.763425] rewind_stack_do_exit+0x17/0x20 > [ 0.763425] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x00000009 > > > metadata: > git branch: master > git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git describe: v5.6-rc4 > kernel-config: > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-mainline/2502/config > > git log --online > 98d54f81e36b (HEAD -> master, tag: v5.6-rc4, origin/master, > origin/HEAD) Linux 5.6-rc4 > e70869821a46 Merge tag 'ext4_for_linus_stable' of > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 > f853ed90e2e4 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm > 86f7e90ce840 KVM: VMX: check descriptor table exits on instruction emulation > fb279f4e2386 Merge branch 'i2c/for-current-fixed' of > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > 37b0b6b8b99c ext4: potential crash on allocation error in > ext4_alloc_flex_bg_array() > 38b17afb0ebb macintosh: therm_windtunnel: fix regression when > instantiating devices > 6c5d91124929 jbd2: fix data races at struct journal_head > 7557c1b3f715 Merge tag 'scsi-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi > > > ref: > https://lkft.validation.linaro.org/scheduler/job/1261774#L461 > https://lkft.validation.linaro.org/scheduler/job/1261816#L477 > > -- > Linaro LKFT > https://lkft.linaro.org ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) 2020-03-02 7:21 ` Wanpeng Li @ 2020-03-02 11:31 ` Anders Roxell 0 siblings, 0 replies; 10+ messages in thread From: Anders Roxell @ 2020-03-02 11:31 UTC (permalink / raw) To: Wanpeng Li Cc: Naresh Kamboju, Paolo Bonzini, kvm list, Linus Torvalds, open list, lkft-triage, oupton, Jim Mattson On Mon, 2 Mar 2020 at 08:21, Wanpeng Li <kernellwp@gmail.com> wrote: > > On Mon, 2 Mar 2020 at 13:39, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > > > On Mon, 2 Mar 2020 at 00:33, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > > > Linus, > > > > > > The following changes since commit a93236fcbe1d0248461b29c0f87cb0b510c94e6f: > > > > > > KVM: s390: rstify new ioctls in api.rst (2020-02-24 19:28:40 +0100) > > > > > > are available in the git repository at: > > > > > > https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus > > > > > > for you to fetch changes up to 86f7e90ce840aa1db407d3ea6e9b3a52b2ce923c: > > > > > > KVM: VMX: check descriptor table exits on instruction emulation (2020-03-01 19:26:31 +0100) > > > > > > ---------------------------------------------------------------- > > > More bugfixes, including a few remaining "make W=1" issues such > > > as too large frame sizes on some configurations. On the > > > ARM side, the compiler was messing up shadow stacks between > > > EL1 and EL2 code, which is easily fixed with __always_inline. > > > > > > ---------------------------------------------------------------- > > > Christian Borntraeger (1): > > > KVM: let declaration of kvm_get_running_vcpus match implementation > > > > > > Erwan Velu (1): > > > kvm: x86: Limit the number of "kvm: disabled by bios" messages > > > > > > James Morse (3): > > > KVM: arm64: Ask the compiler to __always_inline functions used at HYP > > > KVM: arm64: Define our own swab32() to avoid a uapi static inline > > > arm64: Ask the compiler to __always_inline functions used by KVM at HYP > > > > > > Jeremy Cline (1): > > > KVM: arm/arm64: Fix up includes for trace.h > > > > > > Mark Rutland (1): > > > kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() > > > > > > Oliver Upton (1): > > > KVM: VMX: check descriptor table exits on instruction emulation > > > > > > Paolo Bonzini (4): > > > KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter > > > KVM: allow disabling -Werror > > > KVM: x86: avoid useless copy of cpufreq policy > > > Merge tag 'kvmarm-fixes-5.6-1' of git://git.kernel.org/.../kvmarm/kvmarm into HEAD > > > > > > Valdis Kletnieks (1): > > > KVM: x86: allow compiling as non-module with W=1 > > > > > > Wanpeng Li (2): > > > KVM: Introduce pv check helpers > > > KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis > > > > Kernel panic noticed on latest Linux mainline kernel. > > qemu_x86_64 boot failed due to kernel panic. > > Please investigate this problem. > > > > Just give a quick shot. https://lkml.org/lkml/2020/3/2/78 I gave it a quick test and it worked. Cheers, Anders > > > Meanwhile we will also investigate by using git bisect to identify bad patch. > > > > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic \ > > -net nic,model=virtio,macaddr=DE:AD:BE:EF:66:05 -net tap \ > > -m 1024 -monitor none -kernel > > bzImage--5.5+git0+98d54f81e3-r0-intel-corei7-64-20200301225337-2502.bin > > \ > > --append "root=/dev/sda rootwait console=ttyS0,115200" \ > > -hda rpb-console-image-lkft-intel-corei7-64-20200301225337-2502.rootfs.ext4 \ > > -m 4096 -smp 4 -nographic \ > > -drive format=qcow2,file=lava-guest.qcow2,media=disk,if=virtio,id=lavatest > > > > [ 0.000000] Linux version 5.6.0-rc4 (oe-user@oe-host) (gcc version > > 7.3.0 (GCC)) #1 SMP Sun Mar 1 22:59:08 UTC 2020 > > <trim> > > [ 0.762542] kvm: no hardware support > > [ 0.763123] BUG: kernel NULL pointer dereference, address: 000000000000028c > > [ 0.763425] #PF: supervisor read access in kernel mode > > [ 0.763425] #PF: error_code(0x0000) - not-present page > > [ 0.763425] PGD 0 P4D 0 > > [ 0.763425] Oops: 0000 [#1] SMP NOPTI > > [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4 #1 > > [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > BIOS 1.12.0-1 04/01/2014 > > [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 > > [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e > > 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 > > 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f > > c1 43 > > [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 > > [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 > > [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 > > [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 > > [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be > > [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) > > knlGS:0000000000000000 > > [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 > > [ 0.763425] Call Trace: > > [ 0.763425] cpufreq_cpu_put+0x15/0x20 > > [ 0.763425] kvm_arch_init+0x1f6/0x2b0 > > [ 0.763425] kvm_init+0x31/0x290 > > [ 0.763425] ? svm_check_processor_compat+0xd/0xd > > [ 0.763425] ? svm_check_processor_compat+0xd/0xd > > [ 0.763425] svm_init+0x21/0x23 > > [ 0.763425] do_one_initcall+0x61/0x2f0 > > [ 0.763425] ? rdinit_setup+0x30/0x30 > > [ 0.763425] ? rcu_read_lock_sched_held+0x4f/0x80 > > [ 0.763425] kernel_init_freeable+0x219/0x279 > > [ 0.763425] ? rest_init+0x250/0x250 > > [ 0.763425] kernel_init+0xe/0x110 > > [ 0.763425] ret_from_fork+0x27/0x50 > > [ 0.763425] Modules linked in: > > [ 0.763425] CR2: 000000000000028c > > [ 0.763425] ---[ end trace 239abf40c55c409b ]--- > > [ 0.763425] RIP: 0010:kobject_put+0x12/0x1c0 > > [ 0.763425] Code: 4a 01 89 d0 f0 0f b1 0f 75 ef 89 d1 eb d9 66 2e > > 0f 1f 84 00 00 00 00 00 48 85 ff 0f 84 bd 00 00 00 55 48 89 e5 41 55 > > 41 54 53 <f6> 47 3c 01 48 89 fb 74 22 48 8d 7b 38 b8 ff ff ff ff f0 0f > > c1 43 > > [ 0.763425] RSP: 0018:ffffbd2800013de8 EFLAGS: 00010206 > > [ 0.763425] RAX: 0000000000000000 RBX: ffffffff996e9660 RCX: 0000000000000000 > > [ 0.763425] RDX: 0000000000000046 RSI: 0000000000000006 RDI: 0000000000000250 > > [ 0.763425] RBP: ffffbd2800013e00 R08: 0000000000000000 R09: 0000000000000000 > > [ 0.763425] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > [ 0.763425] R13: 0000000000003ad0 R14: 0000000000000000 R15: ffffffff99a896be > > [ 0.763425] FS: 0000000000000000(0000) GS:ffff92ec7bc00000(0000) > > knlGS:0000000000000000 > > [ 0.763425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 0.763425] CR2: 000000000000028c CR3: 0000000049c10000 CR4: 00000000003406f0 > > [ 0.763425] BUG: sleeping function called from invalid context at > > /usr/src/kernel/include/linux/percpu-rwsem.h:38 > > [ 0.763425] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: > > 1, name: swapper/0 > > [ 0.763425] INFO: lockdep is turned off. > > [ 0.763425] irq event stamp: 696816 > > [ 0.763425] hardirqs last enabled at (696815): > > [<ffffffff98c929d1>] _raw_read_unlock_irqrestore+0x31/0x50 > > [ 0.763425] hardirqs last disabled at (696816): > > [<ffffffff97e01f3b>] trace_hardirqs_off_thunk+0x1a/0x1c > > [ 0.763425] softirqs last enabled at (696776): > > [<ffffffff99000338>] __do_softirq+0x338/0x43a > > [ 0.763425] softirqs last disabled at (696769): > > [<ffffffff97f045e8>] irq_exit+0xb8/0xc0 > > [ 0.763425] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D > > 5.6.0-rc4 #1 > > [ 0.763425] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > BIOS 1.12.0-1 04/01/2014 > > [ 0.763425] Call Trace: > > [ 0.763425] dump_stack+0x7a/0xa5 > > [ 0.763425] ___might_sleep+0x163/0x250 > > [ 0.763425] __might_sleep+0x4a/0x80 > > [ 0.763425] exit_signals+0x33/0x2d0 > > [ 0.763425] do_exit+0xb6/0xcf0 > > [ 0.763425] ? kernel_init_freeable+0x219/0x279 > > [ 0.763425] ? rest_init+0x250/0x250 > > [ 0.763425] rewind_stack_do_exit+0x17/0x20 > > [ 0.763425] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x00000009 > > > > > > metadata: > > git branch: master > > git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git describe: v5.6-rc4 > > kernel-config: > > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-mainline/2502/config > > > > git log --online > > 98d54f81e36b (HEAD -> master, tag: v5.6-rc4, origin/master, > > origin/HEAD) Linux 5.6-rc4 > > e70869821a46 Merge tag 'ext4_for_linus_stable' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 > > f853ed90e2e4 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm > > 86f7e90ce840 KVM: VMX: check descriptor table exits on instruction emulation > > fb279f4e2386 Merge branch 'i2c/for-current-fixed' of > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > > 37b0b6b8b99c ext4: potential crash on allocation error in > > ext4_alloc_flex_bg_array() > > 38b17afb0ebb macintosh: therm_windtunnel: fix regression when > > instantiating devices > > 6c5d91124929 jbd2: fix data races at struct journal_head > > 7557c1b3f715 Merge tag 'scsi-fixes' of > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi > > > > > > ref: > > https://lkft.validation.linaro.org/scheduler/job/1261774#L461 > > https://lkft.validation.linaro.org/scheduler/job/1261816#L477 > > > > -- > > Linaro LKFT > > https://lkft.linaro.org ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-03-02 12:15 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-01 19:03 [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5) Paolo Bonzini 2020-03-01 21:33 ` Linus Torvalds 2020-03-01 23:04 ` Paolo Bonzini 2020-03-02 5:10 ` Nathan Chancellor 2020-03-02 10:51 ` Michael Ellerman 2020-03-02 12:14 ` Segher Boessenkool 2020-03-01 22:45 ` pr-tracker-bot 2020-03-02 5:38 ` Naresh Kamboju 2020-03-02 7:21 ` Wanpeng Li 2020-03-02 11:31 ` Anders Roxell
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).