1. 28 12月, 2014 1 次提交
  2. 15 12月, 2014 2 次提交
    • C
      arm/arm64: KVM: Require in-kernel vgic for the arch timers · 05971120
      Christoffer Dall 提交于
      It is curently possible to run a VM with architected timers support
      without creating an in-kernel VGIC, which will result in interrupts from
      the virtual timer going nowhere.
      
      To address this issue, move the architected timers initialization to the
      time when we run a VCPU for the first time, and then only initialize
      (and enable) the architected timers if we have a properly created and
      initialized in-kernel VGIC.
      
      When injecting interrupts from the virtual timer to the vgic, the
      current setup should ensure that this never calls an on-demand init of
      the VGIC, which is the only call path that could return an error from
      kvm_vgic_inject_irq(), so capture the return value and raise a warning
      if there's an error there.
      
      We also change the kvm_timer_init() function from returning an int to be
      a void function, since the function always succeeds.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      05971120
    • C
      arm/arm64: KVM: Initialize the vgic on-demand when injecting IRQs · ca7d9c82
      Christoffer Dall 提交于
      Userspace assumes that it can wire up IRQ injections after having
      created all VCPUs and after having created the VGIC, but potentially
      before starting the first VCPU.  This can currently lead to lost IRQs
      because the state of that IRQ injection is not stored anywhere and we
      don't return an error to userspace.
      
      We haven't seen this problem manifest itself yet, presumably because
      guests reset the devices on boot, but this could cause issues with
      migration and other non-standard startup configurations.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      ca7d9c82
  3. 13 12月, 2014 3 次提交
  4. 04 12月, 2014 6 次提交
  5. 26 11月, 2014 3 次提交
  6. 25 11月, 2014 3 次提交
  7. 24 11月, 2014 1 次提交
  8. 22 11月, 2014 1 次提交
  9. 20 11月, 2014 1 次提交
  10. 17 11月, 2014 2 次提交
  11. 14 11月, 2014 2 次提交
  12. 03 11月, 2014 2 次提交
  13. 24 10月, 2014 2 次提交
    • W
      kvm: vfio: fix unregister kvm_device_ops of vfio · 571ee1b6
      Wanpeng Li 提交于
      After commit 80ce1639 (KVM: VFIO: register kvm_device_ops dynamically),
      kvm_device_ops of vfio can be registered dynamically. Commit 3c3c29fd
      (kvm-vfio: do not use module_init) move the dynamic register invoked by
      kvm_init in order to fix broke unloading of the kvm module. However,
      kvm_device_ops of vfio is unregistered after rmmod kvm-intel module
      which lead to device type collision detection warning after kvm-intel
      module reinsmod.
      
          WARNING: CPU: 1 PID: 10358 at /root/cathy/kvm/arch/x86/kvm/../../../virt/kvm/kvm_main.c:3289 kvm_init+0x234/0x282 [kvm]()
          Modules linked in: kvm_intel(O+) kvm(O) nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4 dns_resolver nfs fscache lockd sunrpc pci_stub bridge stp llc autofs4 8021q cpufreq_ondemand ipv6 joydev microcode pcspkr igb i2c_algo_bit ehci_pci ehci_hcd e1000e i2c_i801 ixgbe ptp pps_core hwmon mdio tpm_tis tpm ipmi_si ipmi_msghandler acpi_cpufreq isci libsas scsi_transport_sas button dm_mirror dm_region_hash dm_log dm_mod [last unloaded: kvm_intel]
          CPU: 1 PID: 10358 Comm: insmod Tainted: G        W  O   3.17.0-rc1 #2
          Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
           0000000000000cd9 ffff880ff08cfd18 ffffffff814a61d9 0000000000000cd9
           0000000000000000 ffff880ff08cfd58 ffffffff810417b7 ffff880ff08cfd48
           ffffffffa045bcac ffffffffa049c420 0000000000000040 00000000000000ff
          Call Trace:
           [<ffffffff814a61d9>] dump_stack+0x49/0x60
           [<ffffffff810417b7>] warn_slowpath_common+0x7c/0x96
           [<ffffffffa045bcac>] ? kvm_init+0x234/0x282 [kvm]
           [<ffffffff810417e6>] warn_slowpath_null+0x15/0x17
           [<ffffffffa045bcac>] kvm_init+0x234/0x282 [kvm]
           [<ffffffffa016e995>] vmx_init+0x1bf/0x42a [kvm_intel]
           [<ffffffffa016e7d6>] ? vmx_check_processor_compat+0x64/0x64 [kvm_intel]
           [<ffffffff810002ab>] do_one_initcall+0xe3/0x170
           [<ffffffff811168a9>] ? __vunmap+0xad/0xb8
           [<ffffffff8109c58f>] do_init_module+0x2b/0x174
           [<ffffffff8109d414>] load_module+0x43e/0x569
           [<ffffffff8109c6d8>] ? do_init_module+0x174/0x174
           [<ffffffff8109c75a>] ? copy_module_from_user+0x39/0x82
           [<ffffffff8109b7dd>] ? module_sect_show+0x20/0x20
           [<ffffffff8109d65f>] SyS_init_module+0x54/0x81
           [<ffffffff814a9a12>] system_call_fastpath+0x16/0x1b
          ---[ end trace 0626f4a3ddea56f3 ]---
      
      The bug can be reproduced by:
      
          rmmod kvm_intel.ko
          insmod kvm_intel.ko
      
      without rmmod/insmod kvm.ko
      This patch fixes the bug by unregistering kvm_device_ops of vfio when the
      kvm-intel module is removed.
      Reported-by: NLiu Rongrong <rongrongx.liu@intel.com>
      Fixes: 3c3c29fdSigned-off-by: NWanpeng Li <wanpeng.li@linux.intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      571ee1b6
    • Q
      kvm: fix excessive pages un-pinning in kvm_iommu_map error path. · 3d32e4db
      Quentin Casasnovas 提交于
      The third parameter of kvm_unpin_pages() when called from
      kvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin
      and not the page size.
      
      This error was facilitated with an inconsistent API: kvm_pin_pages() takes
      a size, but kvn_unpin_pages() takes a number of pages, so fix the problem
      by matching the two.
      
      This was introduced by commit 350b8bdd ("kvm: iommu: fix the third parameter
      of kvm_iommu_put_pages (CVE-2014-3601)"), which fixes the lack of
      un-pinning for pages intended to be un-pinned (i.e. memory leak) but
      unfortunately potentially aggravated the number of pages we un-pin that
      should have stayed pinned. As far as I understand though, the same
      practical mitigations apply.
      
      This issue was found during review of Red Hat 6.6 patches to prepare
      Ksplice rebootless updates.
      
      Thanks to Vegard for his time on a late Friday evening to help me in
      understanding this code.
      
      Fixes: 350b8bdd ("kvm: iommu: fix the third parameter of... (CVE-2014-3601)")
      Cc: stable@vger.kernel.org
      Signed-off-by: NQuentin Casasnovas <quentin.casasnovas@oracle.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: NJamie Iles <jamie.iles@oracle.com>
      Reviewed-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3d32e4db
  14. 16 10月, 2014 1 次提交
  15. 10 10月, 2014 1 次提交
  16. 26 9月, 2014 2 次提交
  17. 25 9月, 2014 1 次提交
  18. 24 9月, 2014 6 次提交