On 25/11/2017 02:59, Linus Torvalds wrote: > > > On Nov 23, 2017 23:36, "Paolo Bonzini" <pbonzini@xxxxxxxxxx > <mailto:pbonzini@xxxxxxxxxx>> wrote: > > On 24/11/2017 04:50, Linus Torvalds wrote: > > > > So I pulled it, but then checked, > > > > None of this was in linux-next 20171117 either, > > > > So I unpulled it, > > The ARM parts certainly were. > > Were those rebased or something? They came from the submaintainers' tree, so technically it wasn't in *my* linux-next tree; if you looked at "linux-next as of the kvm/linux-next merge", you wouldn't have found them. But they were not rebased at least between 20171113 and 20171117: +Merging kvm-arm/next (95b110ab9a09 KVM: arm/arm64: Don't queue VLPIs on INV/INVALL) +$ git merge kvm-arm/next +Auto-merging virt/kvm/arm/vgic/vgic-its.c +Auto-merging virt/kvm/arm/arm.c +Auto-merging arch/arm64/kvm/Makefile +Auto-merging arch/arm64/kvm/Kconfig +Auto-merging arch/arm/kvm/Makefile +Auto-merging arch/arm/kvm/Kconfig +Auto-merging Documentation/admin-guide/kernel-parameters.txt +Merge made by the 'recursive' strategy. + Documentation/admin-guide/kernel-parameters.txt | 4 + + Documentation/virtual/kvm/devices/arm-vgic-its.txt | 2 + + arch/arm/kvm/Kconfig | 5 + + arch/arm/kvm/Makefile | 1 + + arch/arm64/kvm/Kconfig | 3 + + arch/arm64/kvm/Makefile | 1 + + include/kvm/arm_vgic.h | 41 ++- + virt/kvm/arm/arch_timer.c | 24 +- + virt/kvm/arm/arm.c | 48 ++- + virt/kvm/arm/hyp/vgic-v3-sr.c | 9 +- + virt/kvm/arm/vgic/vgic-init.c | 7 + + virt/kvm/arm/vgic/vgic-its.c | 204 ++++++++---- + virt/kvm/arm/vgic/vgic-mmio-v3.c | 5 + + virt/kvm/arm/vgic/vgic-v3.c | 14 + + virt/kvm/arm/vgic/vgic-v4.c | 364 +++++++++++++++++++++ + virt/kvm/arm/vgic/vgic.c | 67 +++- + virt/kvm/arm/vgic/vgic.h | 10 + + 17 files changed, 695 insertions(+), 114 deletions(-) + create mode 100644 virt/kvm/arm/vgic/vgic-v4.c (from https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/diff/Next/merge.log?h=next-20171113&id=c348a99ee55feac43b5b62a5957c6d8e2b6c3abe) > One of the issues with rebasing is literally that it just looks like a > different commit entirely. If you then mix stuff in that really wasn't > there in any form at all, it *all* looks new. No, KVM pretty much never rebases what goes in linux-next (this applies to both the generic+x86 tree that Radim and I maintain, and the submaintainer trees). This does have the side effect of giving slightly less linux-next exposure to very early bugfixes, which is exactly what happened for this pull request. We'll fix that. For UMIP, the main reason for me to include it wasn't really the KVM parts, but rather making it possible to test core UMIP support through KVM's emulation. But it was indeed a bit fast-and-loose, so, lesson learnt. Thanks, Paolo Paolo
