1. 28 9月, 2015 1 次提交
  2. 21 9月, 2015 1 次提交
  3. 16 9月, 2015 1 次提交
    • P
      KVM: add halt_attempted_poll to VCPU stats · 62bea5bf
      Paolo Bonzini 提交于
      This new statistic can help diagnosing VCPUs that, for any reason,
      trigger bad behavior of halt_poll_ns autotuning.
      
      For example, say halt_poll_ns = 480000, and wakeups are spaced exactly
      like 479us, 481us, 479us, 481us. Then KVM always fails polling and wastes
      10+20+40+80+160+320+480 = 1110 microseconds out of every
      479+481+479+481+479+481+479 = 3359 microseconds. The VCPU then
      is consuming about 30% more CPU than it would use without
      polling.  This would show as an abnormally high number of
      attempted polling compared to the successful polls.
      
      Acked-by: Christian Borntraeger <borntraeger@de.ibm.com<
      Reviewed-by: NDavid Matlack <dmatlack@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      62bea5bf
  4. 06 9月, 2015 1 次提交
  5. 07 8月, 2015 2 次提交
    • H
      KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST · d7add054
      Haozhong Zhang 提交于
      When kvm_set_msr_common() handles a guest's write to
      MSR_IA32_TSC_ADJUST, it will calcuate an adjustment based on the data
      written by guest and then use it to adjust TSC offset by calling a
      call-back adjust_tsc_offset(). The 3rd parameter of adjust_tsc_offset()
      indicates whether the adjustment is in host TSC cycles or in guest TSC
      cycles. If SVM TSC scaling is enabled, adjust_tsc_offset()
      [i.e. svm_adjust_tsc_offset()] will first scale the adjustment;
      otherwise, it will just use the unscaled one. As the MSR write here
      comes from the guest, the adjustment is in guest TSC cycles. However,
      the current kvm_set_msr_common() uses it as a value in host TSC
      cycles (by using true as the 3rd parameter of adjust_tsc_offset()),
      which can result in an incorrect adjustment of TSC offset if SVM TSC
      scaling is enabled. This patch fixes this problem.
      Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com>
      Cc: stable@vger.linux.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d7add054
    • P
      KVM: x86: zero IDT limit on entry to SMM · 18c3626e
      Paolo Bonzini 提交于
      The recent BlackHat 2015 presentation "The Memory Sinkhole"
      mentions that the IDT limit is zeroed on entry to SMM.
      
      This is not documented, and must have changed some time after 2010
      (see http://www.ssi.gouv.fr/uploads/IMG/pdf/IT_Defense_2010_final.pdf).
      KVM was not doing it, but the fix is easy.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      18c3626e
  6. 05 8月, 2015 1 次提交
  7. 30 7月, 2015 1 次提交
    • P
      KVM: x86: clean/fix memory barriers in irqchip_in_kernel · 71ba994c
      Paolo Bonzini 提交于
      The memory barriers are trying to protect against concurrent RCU-based
      interrupt injection, but the IRQ routing table is not valid at the time
      kvm->arch.vpic is written.  Fix this by writing kvm->arch.vpic last.
      kvm_destroy_pic then need not set kvm->arch.vpic to NULL; modify it
      to take a struct kvm_pic* and reuse it if the IOAPIC creation fails.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      71ba994c
  8. 29 7月, 2015 2 次提交
  9. 23 7月, 2015 3 次提交
  10. 10 7月, 2015 3 次提交
    • W
      kvm: x86: fix load xsave feature warning · ee4100da
      Wanpeng Li 提交于
      [   68.196974] WARNING: CPU: 1 PID: 2140 at arch/x86/kvm/x86.c:3161 kvm_arch_vcpu_ioctl+0xe88/0x1340 [kvm]()
      [   68.196975] Modules linked in: snd_hda_codec_hdmi i915 rfcomm bnep bluetooth i2c_algo_bit rfkill nfsd drm_kms_helper nfs_acl nfs drm lockd grace sunrpc fscache snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_dummy snd_seq_oss x86_pkg_temp_thermal snd_seq_midi kvm_intel snd_seq_midi_event snd_rawmidi kvm snd_seq ghash_clmulni_intel fuse snd_timer aesni_intel parport_pc ablk_helper snd_seq_device cryptd ppdev snd lp parport lrw dcdbas gf128mul i2c_core glue_helper lpc_ich video shpchp mfd_core soundcore serio_raw acpi_cpufreq ext4 mbcache jbd2 sd_mod crc32c_intel ahci libahci libata e1000e ptp pps_core
      [   68.197005] CPU: 1 PID: 2140 Comm: qemu-system-x86 Not tainted 4.2.0-rc1+ #2
      [   68.197006] Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015
      [   68.197007]  ffffffffa03b0657 ffff8800d984bca8 ffffffff815915a2 0000000000000000
      [   68.197009]  0000000000000000 ffff8800d984bce8 ffffffff81057c0a 00007ff6d0001000
      [   68.197010]  0000000000000002 ffff880211c1a000 0000000000000004 ffff8800ce0288c0
      [   68.197012] Call Trace:
      [   68.197017]  [<ffffffff815915a2>] dump_stack+0x45/0x57
      [   68.197020]  [<ffffffff81057c0a>] warn_slowpath_common+0x8a/0xc0
      [   68.197022]  [<ffffffff81057cfa>] warn_slowpath_null+0x1a/0x20
      [   68.197029]  [<ffffffffa037bed8>] kvm_arch_vcpu_ioctl+0xe88/0x1340 [kvm]
      [   68.197035]  [<ffffffffa037aede>] ? kvm_arch_vcpu_load+0x4e/0x1c0 [kvm]
      [   68.197040]  [<ffffffffa03696a6>] kvm_vcpu_ioctl+0xc6/0x5c0 [kvm]
      [   68.197043]  [<ffffffff811252d2>] ? perf_pmu_enable+0x22/0x30
      [   68.197044]  [<ffffffff8112663e>] ? perf_event_context_sched_in+0x7e/0xb0
      [   68.197048]  [<ffffffff811a6882>] do_vfs_ioctl+0x2c2/0x4a0
      [   68.197050]  [<ffffffff8107bf33>] ? finish_task_switch+0x173/0x220
      [   68.197053]  [<ffffffff8123307f>] ? selinux_file_ioctl+0x4f/0xd0
      [   68.197055]  [<ffffffff8122cac3>] ? security_file_ioctl+0x43/0x60
      [   68.197057]  [<ffffffff811a6ad9>] SyS_ioctl+0x79/0x90
      [   68.197060]  [<ffffffff81597e57>] entry_SYSCALL_64_fastpath+0x12/0x6a
      [   68.197061] ---[ end trace 558a5ebf9445fc80 ]---
      
      After commit (0c4109be 'x86/fpu/xstate: Fix up bad get_xsave_addr()
      assumptions'), there is no assumption an xsave bit is present in the
      hardware (pcntxt_mask) that it is always present in a given xsave buffer.
      An enabled state to be present on 'pcntxt_mask', but *not* in 'xstate_bv'
      could happen when the last 'xsave' did not request that this feature be
      saved (unlikely) or because the "init optimization" caused it to not be
      saved. This patch kill the assumption.
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      ee4100da
    • P
      KVM: count number of assigned devices · 5544eb9b
      Paolo Bonzini 提交于
      If there are no assigned devices, the guest PAT are not providing
      any useful information and can be overridden to writeback; VMX
      always does this because it has the "IPAT" bit in its extended
      page table entries, but SVM does not have anything similar.
      Hook into VFIO and legacy device assignment so that they
      provide this information to KVM.
      Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
      Tested-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5544eb9b
    • R
      KVM: VMX: fix vmwrite to invalid VMCS · 370777da
      Radim Krčmář 提交于
      fpu_activate is called outside of vcpu_load(), which means it should not
      touch VMCS, but fpu_activate needs to.  Avoid the call by moving it to a
      point where we know that the guest needs eager FPU and VMCS is loaded.
      
      This will get rid of the following trace
      
       vmwrite error: reg 6800 value 0 (err 1)
        [<ffffffff8162035b>] dump_stack+0x19/0x1b
        [<ffffffffa046c701>] vmwrite_error+0x2c/0x2e [kvm_intel]
        [<ffffffffa045f26f>] vmcs_writel+0x1f/0x30 [kvm_intel]
        [<ffffffffa04617e5>] vmx_fpu_activate.part.61+0x45/0xb0 [kvm_intel]
        [<ffffffffa0461865>] vmx_fpu_activate+0x15/0x20 [kvm_intel]
        [<ffffffffa0560b91>] kvm_arch_vcpu_create+0x51/0x70 [kvm]
        [<ffffffffa0548011>] kvm_vm_ioctl+0x1c1/0x760 [kvm]
        [<ffffffff8118b55a>] ? handle_mm_fault+0x49a/0xec0
        [<ffffffff811e47d5>] do_vfs_ioctl+0x2e5/0x4c0
        [<ffffffff8127abbe>] ? file_has_perm+0xae/0xc0
        [<ffffffff811e4a51>] SyS_ioctl+0xa1/0xc0
        [<ffffffff81630949>] system_call_fastpath+0x16/0x1b
      
      (Note: we also unconditionally activate FPU in vmx_vcpu_reset(), so the
       removed code added nothing.)
      
      Fixes: c447e76b ("kvm/fpu: Enable eager restore kvm FPU for MPX")
      Cc: <stable@vger.kernel.org>
      Reported-by: NVlastimil Holer <vlastimil.holer@gmail.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      370777da
  11. 06 7月, 2015 3 次提交
  12. 04 7月, 2015 1 次提交
  13. 23 6月, 2015 1 次提交
  14. 19 6月, 2015 7 次提交
  15. 05 6月, 2015 4 次提交
  16. 04 6月, 2015 8 次提交