<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/x86/kvm, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-08-07T11:28:03+00:00</updated>
<entry>
<title>KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST</title>
<updated>2015-08-07T11:28:03+00:00</updated>
<author>
<name>Haozhong Zhang</name>
<email>haozhong.zhang@intel.com</email>
</author>
<published>2015-08-07T03:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d7add05458084a5e3d65925764a02ca9c8202c1e'/>
<id>urn:sha1:d7add05458084a5e3d65925764a02ca9c8202c1e</id>
<content type='text'>
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: Haozhong Zhang &lt;haozhong.zhang@intel.com&gt;
Cc: stable@vger.linux.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: x86: zero IDT limit on entry to SMM</title>
<updated>2015-08-07T10:46:32+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2015-08-07T10:27:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=18c3626e3d5dfa8b90e2dc6dbc30064c0e1c97ad'/>
<id>urn:sha1:18c3626e3d5dfa8b90e2dc6dbc30064c0e1c97ad</id>
<content type='text'>
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: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON</title>
<updated>2015-08-05T09:57:57+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2015-08-04T16:58:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fc1a8126bf8095b10f5a79893f2d2b19227f88f2'/>
<id>urn:sha1:fc1a8126bf8095b10f5a79893f2d2b19227f88f2</id>
<content type='text'>
The patch was munged on commit to re-order these tests resulting in
excessive warnings when trying to do device assignment.  Return to
original ordering: https://lkml.org/lkml/2015/7/15/769

Fixes: 3e5d2fdceda1 ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Reviewed-by: Xiao Guangrong &lt;guangrong.xiao@linux.intel.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: x86: rename quirk constants to KVM_X86_QUIRK_*</title>
<updated>2015-07-23T06:24:42+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2015-07-23T06:24:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0da029ed7ee5fdf49a2a0e14160c3e9999be9292'/>
<id>urn:sha1:0da029ed7ee5fdf49a2a0e14160c3e9999be9292</id>
<content type='text'>
Make them clearly architecture-dependent; the capability is valid for
all architectures, but the argument is not.

Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED</title>
<updated>2015-07-23T06:23:01+00:00</updated>
<author>
<name>Xiao Guangrong</name>
<email>guangrong.xiao@intel.com</email>
</author>
<published>2015-07-15T19:25:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fb279950ba02e3210a16b11ecfa8871f3ee0ca49'/>
<id>urn:sha1:fb279950ba02e3210a16b11ecfa8871f3ee0ca49</id>
<content type='text'>
OVMF depends on WB to boot fast, because it only clears caches after
it has set up MTRRs---which is too late.

Let's do writeback if CR0.CD is set to make it happy, similar to what
SVM is already doing.

Signed-off-by: Xiao Guangrong &lt;guangrong.xiao@intel.com&gt;
Tested-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: x86: introduce kvm_check_has_quirk</title>
<updated>2015-07-23T06:22:45+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2015-07-23T06:22:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=41dbc6bcd9722bba8f09256655d060af30c63d34'/>
<id>urn:sha1:41dbc6bcd9722bba8f09256655d060af30c63d34</id>
<content type='text'>
The logic of the disabled_quirks field usually results in a double
negation.  Wrap it in a simple function that checks the bit and
negates it.

Based on a patch from Xiao Guangrong.

Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type</title>
<updated>2015-07-23T06:21:48+00:00</updated>
<author>
<name>Xiao Guangrong</name>
<email>guangrong.xiao@intel.com</email>
</author>
<published>2015-07-15T19:25:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3e5d2fdceda172554e681b68c853bf5d08205bbf'/>
<id>urn:sha1:3e5d2fdceda172554e681b68c853bf5d08205bbf</id>
<content type='text'>
kvm_mtrr_get_guest_memory_type never returns -1 which is implied
in the current code since if @type = -1 (means no MTRR contains the
range), iter.partial_map must be true

Simplify the code to indicate this fact

Signed-off-by: Xiao Guangrong &lt;guangrong.xiao@intel.com&gt;
Tested-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: MTRR: fix memory type handling if MTRR is completely disabled</title>
<updated>2015-07-23T06:21:33+00:00</updated>
<author>
<name>Xiao Guangrong</name>
<email>guangrong.xiao@intel.com</email>
</author>
<published>2015-07-15T19:25:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=10dc331ff5e7e4668c0f0c95b1a873aba9b70826'/>
<id>urn:sha1:10dc331ff5e7e4668c0f0c95b1a873aba9b70826</id>
<content type='text'>
Currently code uses default memory type if MTRR is fully disabled,
fix it by using UC instead.

Signed-off-by: Xiao Guangrong &lt;guangrong.xiao@intel.com&gt;
Tested-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>kvm: x86: fix load xsave feature warning</title>
<updated>2015-07-10T11:26:45+00:00</updated>
<author>
<name>Wanpeng Li</name>
<email>wanpeng.li@hotmail.com</email>
</author>
<published>2015-07-09T07:44:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ee4100da1616d6d151f97862b87e8a4e43d14b4c'/>
<id>urn:sha1:ee4100da1616d6d151f97862b87e8a4e43d14b4c</id>
<content type='text'>
[   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]  [&lt;ffffffff815915a2&gt;] dump_stack+0x45/0x57
[   68.197020]  [&lt;ffffffff81057c0a&gt;] warn_slowpath_common+0x8a/0xc0
[   68.197022]  [&lt;ffffffff81057cfa&gt;] warn_slowpath_null+0x1a/0x20
[   68.197029]  [&lt;ffffffffa037bed8&gt;] kvm_arch_vcpu_ioctl+0xe88/0x1340 [kvm]
[   68.197035]  [&lt;ffffffffa037aede&gt;] ? kvm_arch_vcpu_load+0x4e/0x1c0 [kvm]
[   68.197040]  [&lt;ffffffffa03696a6&gt;] kvm_vcpu_ioctl+0xc6/0x5c0 [kvm]
[   68.197043]  [&lt;ffffffff811252d2&gt;] ? perf_pmu_enable+0x22/0x30
[   68.197044]  [&lt;ffffffff8112663e&gt;] ? perf_event_context_sched_in+0x7e/0xb0
[   68.197048]  [&lt;ffffffff811a6882&gt;] do_vfs_ioctl+0x2c2/0x4a0
[   68.197050]  [&lt;ffffffff8107bf33&gt;] ? finish_task_switch+0x173/0x220
[   68.197053]  [&lt;ffffffff8123307f&gt;] ? selinux_file_ioctl+0x4f/0xd0
[   68.197055]  [&lt;ffffffff8122cac3&gt;] ? security_file_ioctl+0x43/0x60
[   68.197057]  [&lt;ffffffff811a6ad9&gt;] SyS_ioctl+0x79/0x90
[   68.197060]  [&lt;ffffffff81597e57&gt;] entry_SYSCALL_64_fastpath+0x12/0x6a
[   68.197061] ---[ end trace 558a5ebf9445fc80 ]---

After commit (0c4109bec0 '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: Wanpeng Li &lt;wanpeng.li@hotmail.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: x86: apply guest MTRR virtualization on host reserved pages</title>
<updated>2015-07-10T11:25:27+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2015-07-07T12:38:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fd717f11015f673487ffc826e59b2bad69d20fe5'/>
<id>urn:sha1:fd717f11015f673487ffc826e59b2bad69d20fe5</id>
<content type='text'>
Currently guest MTRR is avoided if kvm_is_reserved_pfn returns true.
However, the guest could prefer a different page type than UC for
such pages. A good example is that pass-throughed VGA frame buffer is
not always UC as host expected.

This patch enables full use of virtual guest MTRRs.

Suggested-by: Xiao Guangrong &lt;guangrong.xiao@linux.intel.com&gt;
Tested-by: Joerg Roedel &lt;jroedel@suse.de&gt; (on AMD)
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
</feed>
