1. 14 3月, 2021 2 次提交
  2. 13 3月, 2021 4 次提交
    • W
      KVM: LAPIC: Advancing the timer expiration on guest initiated write · 35737d2d
      Wanpeng Li 提交于
      Advancing the timer expiration should only be necessary on guest initiated
      writes. When we cancel the timer and clear .pending during state restore,
      clear expired_tscdeadline as well.
      Reviewed-by: NSean Christopherson <seanjc@google.com>
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      Message-Id: <1614818118-965-1-git-send-email-wanpengli@tencent.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      35737d2d
    • S
      KVM: x86/mmu: Skip !MMU-present SPTEs when removing SP in exclusive mode · 8df9f1af
      Sean Christopherson 提交于
      If mmu_lock is held for write, don't bother setting !PRESENT SPTEs to
      REMOVED_SPTE when recursively zapping SPTEs as part of shadow page
      removal.  The concurrent write protections provided by REMOVED_SPTE are
      not needed, there are no backing page side effects to record, and MMIO
      SPTEs can be left as is since they are protected by the memslot
      generation, not by ensuring that the MMIO SPTE is unreachable (which
      is racy with respect to lockless walks regardless of zapping behavior).
      
      Skipping !PRESENT drastically reduces the number of updates needed to
      tear down sparsely populated MMUs, e.g. when tearing down a 6gb VM that
      didn't touch much memory, 6929/7168 (~96.6%) of SPTEs were '0' and could
      be skipped.
      
      Avoiding the write itself is likely close to a wash, but avoiding
      __handle_changed_spte() is a clear-cut win as that involves saving and
      restoring all non-volatile GPRs (it's a subtly big function), as well as
      several conditional branches before bailing out.
      
      Cc: Ben Gardon <bgardon@google.com>
      Signed-off-by: NSean Christopherson <seanjc@google.com>
      Message-Id: <20210310003029.1250571-1-seanjc@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8df9f1af
    • W
      KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged · d7eb79c6
      Wanpeng Li 提交于
      # lscpu
      Architecture:          x86_64
      CPU op-mode(s):        32-bit, 64-bit
      Byte Order:            Little Endian
      CPU(s):                88
      On-line CPU(s) list:   0-63
      Off-line CPU(s) list:  64-87
      
      # cat /proc/cmdline
      BOOT_IMAGE=/vmlinuz-5.10.0-rc3-tlinux2-0050+ root=/dev/mapper/cl-root ro
      rd.lvm.lv=cl/root rhgb quiet console=ttyS0 LANG=en_US .UTF-8 no-kvmclock-vsyscall
      
      # echo 1 > /sys/devices/system/cpu/cpu76/online
      -bash: echo: write error: Cannot allocate memory
      
      The per-cpu vsyscall pvclock data pointer assigns either an element of the
      static array hv_clock_boot (#vCPU <= 64) or dynamically allocated memory
      hvclock_mem (vCPU > 64), the dynamically memory will not be allocated if
      kvmclock vsyscall is disabled, this can result in cpu hotpluged fails in
      kvmclock_setup_percpu() which returns -ENOMEM. It's broken for no-vsyscall
      and sometimes you end up with vsyscall disabled if the host does something
      strange. This patch fixes it by allocating this dynamically memory
      unconditionally even if vsyscall is disabled.
      
      Fixes: 6a1cac56 ("x86/kvm: Use __bss_decrypted attribute in shared variables")
      Reported-by: NZelin Deng <zelin.deng@linux.alibaba.com>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: stable@vger.kernel.org#v4.19-rc5+
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      Message-Id: <1614130683-24137-1-git-send-email-wanpengli@tencent.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d7eb79c6
    • M
      kvm: x86: annotate RCU pointers · 6fcd9cbc
      Muhammad Usama Anjum 提交于
      This patch adds the annotation to fix the following sparse errors:
      arch/x86/kvm//x86.c:8147:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//x86.c:8147:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//x86.c:8147:15:    struct kvm_apic_map *
      arch/x86/kvm//x86.c:10628:16: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//x86.c:10628:16:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//x86.c:10628:16:    struct kvm_apic_map *
      arch/x86/kvm//x86.c:10629:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//x86.c:10629:15:    struct kvm_pmu_event_filter [noderef] __rcu *
      arch/x86/kvm//x86.c:10629:15:    struct kvm_pmu_event_filter *
      arch/x86/kvm//lapic.c:267:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:267:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:267:15:    struct kvm_apic_map *
      arch/x86/kvm//lapic.c:269:9: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:269:9:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:269:9:    struct kvm_apic_map *
      arch/x86/kvm//lapic.c:637:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:637:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:637:15:    struct kvm_apic_map *
      arch/x86/kvm//lapic.c:994:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:994:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:994:15:    struct kvm_apic_map *
      arch/x86/kvm//lapic.c:1036:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:1036:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:1036:15:    struct kvm_apic_map *
      arch/x86/kvm//lapic.c:1173:15: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//lapic.c:1173:15:    struct kvm_apic_map [noderef] __rcu *
      arch/x86/kvm//lapic.c:1173:15:    struct kvm_apic_map *
      arch/x86/kvm//pmu.c:190:18: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//pmu.c:190:18:    struct kvm_pmu_event_filter [noderef] __rcu *
      arch/x86/kvm//pmu.c:190:18:    struct kvm_pmu_event_filter *
      arch/x86/kvm//pmu.c:251:18: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//pmu.c:251:18:    struct kvm_pmu_event_filter [noderef] __rcu *
      arch/x86/kvm//pmu.c:251:18:    struct kvm_pmu_event_filter *
      arch/x86/kvm//pmu.c:522:18: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//pmu.c:522:18:    struct kvm_pmu_event_filter [noderef] __rcu *
      arch/x86/kvm//pmu.c:522:18:    struct kvm_pmu_event_filter *
      arch/x86/kvm//pmu.c:522:18: error: incompatible types in comparison expression (different address spaces):
      arch/x86/kvm//pmu.c:522:18:    struct kvm_pmu_event_filter [noderef] __rcu *
      arch/x86/kvm//pmu.c:522:18:    struct kvm_pmu_event_filter *
      Signed-off-by: NMuhammad Usama Anjum <musamaanjum@gmail.com>
      Message-Id: <20210305191123.GA497469@LEGION>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6fcd9cbc
  3. 12 3月, 2021 2 次提交
    • M
      KVM: arm64: Fix exclusive limit for IPA size · 262b003d
      Marc Zyngier 提交于
      When registering a memslot, we check the size and location of that
      memslot against the IPA size to ensure that we can provide guest
      access to the whole of the memory.
      
      Unfortunately, this check rejects memslot that end-up at the exact
      limit of the addressing capability for a given IPA size. For example,
      it refuses the creation of a 2GB memslot at 0x8000000 with a 32bit
      IPA space.
      
      Fix it by relaxing the check to accept a memslot reaching the
      limit of the IPA space.
      
      Fixes: c3058d5d ("arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE")
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: NAndrew Jones <drjones@redhat.com>
      Link: https://lore.kernel.org/r/20210311100016.3830038-3-maz@kernel.org
      262b003d
    • M
      KVM: arm64: Reject VM creation when the default IPA size is unsupported · 7d717558
      Marc Zyngier 提交于
      KVM/arm64 has forever used a 40bit default IPA space, partially
      due to its 32bit heritage (where the only choice is 40bit).
      
      However, there are implementations in the wild that have a *cough*
      much smaller *cough* IPA space, which leads to a misprogramming of
      VTCR_EL2, and a guest that is stuck on its first memory access
      if userspace dares to ask for the default IPA setting (which most
      VMMs do).
      
      Instead, blundly reject the creation of such VM, as we can't
      satisfy the requirements from userspace (with a one-off warning).
      Also clarify the boot warning, and document that the VM creation
      will fail when an unsupported IPA size is provided.
      
      Although this is an ABI change, it doesn't really change much
      for userspace:
      
      - the guest couldn't run before this change, but no error was
        returned. At least userspace knows what is happening.
      
      - a memory slot that was accepted because it did fit the default
        IPA space now doesn't even get a chance to be registered.
      
      The other thing that is left doing is to convince userspace to
      actually use the IPA space setting instead of relying on the
      antiquated default.
      
      Fixes: 233a7cb2 ("kvm: arm64: Allow tuning the physical address size for VM")
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: NAndrew Jones <drjones@redhat.com>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org
      7d717558
  4. 11 3月, 2021 6 次提交
  5. 10 3月, 2021 6 次提交
  6. 09 3月, 2021 6 次提交
  7. 08 3月, 2021 13 次提交
  8. 06 3月, 2021 1 次提交
    • G
      m68k: Fix virt_addr_valid() W=1 compiler warnings · a65a802a
      Geert Uytterhoeven 提交于
      If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
      
          include/linux/scatterlist.h: In function ‘sg_set_buf’:
          arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of pointer with null pointer [-Wextra]
            174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory)
      	  |                                                 ^~
      
      or CONFIG_MMU=n:
      
          include/linux/scatterlist.h: In function ‘sg_set_buf’:
          arch/m68k/include/asm/page_no.h:33:50: warning: ordered comparison of pointer with null pointer [-Wextra]
             33 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void *)PAGE_OFFSET) && \
      	  |                                                  ^~
      
      Fix this by doing the comparison in the "unsigned long" instead of the
      "void *" domain.
      
      Note that for now this is only seen when compiling btrfs, due to commit
      e9aa7c28 ("btrfs: enable W=1 checks for btrfs"), but as people
      are doing more W=1 compile testing, it will start to show up elsewhere,
      too.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NGreg Ungerer <gerg@linux-m68k.org>
      Link: https://lore.kernel.org/r/20210305084122.4118826-1-geert@linux-m68k.org
      a65a802a
反馈
建议
客服 返回
顶部