<feed xmlns='http://www.w3.org/2005/Atom'>
<title>blaster4385/linux-IllusionX/tools/testing/selftests/kvm/include/x86_64/processor.h, branch v6.13</title>
<subtitle>Linux kernel with personal config changes for arch linux</subtitle>
<id>http://git.tablaster.dev/blaster4385/linux-IllusionX/atom?h=v6.13</id>
<link rel='self' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/atom?h=v6.13'/>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/'/>
<updated>2024-11-01T16:26:31Z</updated>
<entry>
<title>KVM: selftests: Configure XCR0 to max supported value by default</title>
<updated>2024-11-01T16:26:31Z</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2024-10-03T23:43:31Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=8b14c4d85d031f7700fa4e042aebf99d933971f0'/>
<id>urn:sha1:8b14c4d85d031f7700fa4e042aebf99d933971f0</id>
<content type='text'>
To play nice with compilers generating AVX instructions, set CR4.OSXSAVE
and configure XCR0 by default when creating selftests vCPUs.  Some distros
have switched gcc to '-march=x86-64-v3' by default, and while it's hard to
find a CPU which doesn't support AVX today, many KVM selftests fail with

  ==== Test Assertion Failure ====
    lib/x86_64/processor.c:570: Unhandled exception in guest
    pid=72747 tid=72747 errno=4 - Interrupted system call
    Unhandled exception '0x6' at guest RIP '0x4104f7'

due to selftests not enabling AVX by default for the guest.  The failure
is easy to reproduce elsewhere with:

   $ make clean &amp;&amp; CFLAGS='-march=x86-64-v3' make -j &amp;&amp; ./x86_64/kvm_pv_test

E.g. gcc-13 with -march=x86-64-v3 compiles this chunk from selftests'
kvm_fixup_exception():

        regs-&gt;rip = regs-&gt;r11;
        regs-&gt;r9 = regs-&gt;vector;
        regs-&gt;r10 = regs-&gt;error_code;

into this monstronsity (which is clever, but oof):

  405313:       c4 e1 f9 6e c8          vmovq  %rax,%xmm1
  405318:       48 89 68 08             mov    %rbp,0x8(%rax)
  40531c:       48 89 e8                mov    %rbp,%rax
  40531f:       c4 c3 f1 22 c4 01       vpinsrq $0x1,%r12,%xmm1,%xmm0
  405325:       49 89 6d 38             mov    %rbp,0x38(%r13)
  405329:       c5 fa 7f 45 00          vmovdqu %xmm0,0x0(%rbp)

Alternatively, KVM selftests could explicitly restrict the compiler to
-march=x86-64-v2, but odds are very good that punting on AVX enabling will
simply result in tests that "need" AVX doing their own thing, e.g. there
are already three or so additional cleanups that can be done on top.

Reported-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Closes: https://lore.kernel.org/all/20240920154422.2890096-1-vkuznets@redhat.com
Reviewed-and-tested-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Link: https://lore.kernel.org/r/20241003234337.273364-6-seanjc@google.com
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>KVM: selftests: Move Hyper-V specific functions out of processor.c</title>
<updated>2024-08-22T19:14:42Z</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2024-08-16T13:01:38Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=24a7e944966cc8a285e6581dcc98edebeee76c97'/>
<id>urn:sha1:24a7e944966cc8a285e6581dcc98edebeee76c97</id>
<content type='text'>
Since there is 'hyperv.c' for Hyper-V specific functions already, move
Hyper-V specific functions out of processor.c there.

No functional change intended.

Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Link: https://lore.kernel.org/r/20240816130139.286246-2-vkuznets@redhat.com
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-x86-misc-6.11' of https://github.com/kvm-x86/linux into HEAD</title>
<updated>2024-07-16T13:53:05Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2024-07-16T13:53:05Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=5dcc1e76144fcf7bfe182bd98572d1957a380bac'/>
<id>urn:sha1:5dcc1e76144fcf7bfe182bd98572d1957a380bac</id>
<content type='text'>
KVM x86 misc changes for 6.11

 - Add a global struct to consolidate tracking of host values, e.g. EFER, and
   move "shadow_phys_bits" into the structure as "maxphyaddr".

 - Add KVM_CAP_X86_APIC_BUS_CYCLES_NS to allow configuring the effective APIC
   bus frequency, because TDX.

 - Print the name of the APICv/AVIC inhibits in the relevant tracepoint.

 - Clean up KVM's handling of vendor specific emulation to consistently act on
   "compatible with Intel/AMD", versus checking for a specific vendor.

 - Misc cleanups
</content>
</entry>
<entry>
<title>KVM: selftests: Add guest udelay() utility for x86</title>
<updated>2024-06-28T18:40:38Z</updated>
<author>
<name>Reinette Chatre</name>
<email>reinette.chatre@intel.com</email>
</author>
<published>2024-06-12T18:16:11Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=6b878cbb87bf4fc4c07906ada431624911e3d85a'/>
<id>urn:sha1:6b878cbb87bf4fc4c07906ada431624911e3d85a</id>
<content type='text'>
Add udelay() for x86 tests to allow busy waiting in the guest for a
specific duration, and to match ARM and RISC-V's udelay() in the hopes
of eventually making udelay() available on all architectures.

Get the guest's TSC frequency using KVM_GET_TSC_KHZ and expose it to all
VMs via a new global, guest_tsc_khz.  Assert that KVM_GET_TSC_KHZ returns
a valid frequency, instead of simply skipping tests, which would require
detecting which tests actually need/want udelay().  KVM hasn't returned an
error for KVM_GET_TSC_KHZ since commit cc578287e322 ("KVM: Infrastructure
for software and hardware based TSC rate scaling"), which predates KVM
selftests by 6+ years (KVM_GET_TSC_KHZ itself predates KVM selftest by 7+
years).

Note, if the GUEST_ASSERT() in udelay() somehow fires and the test doesn't
check for guest asserts, then the test will fail with a very cryptic
message.  But fixing that, e.g. by automatically handling guest asserts,
is a much larger task, and practically speaking the odds of a test afoul
of this wart are infinitesimally small.

Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Link: https://lore.kernel.org/r/5aa86285d1c1d7fe1960e3fe490f4b22273977e6.1718214999.git.reinette.chatre@intel.com
Co-developed-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>KVM: selftests: x86: Prioritize getting max_gfn from GuestPhysBits</title>
<updated>2024-06-05T13:16:10Z</updated>
<author>
<name>Tao Su</name>
<email>tao1.su@linux.intel.com</email>
</author>
<published>2024-05-13T01:40:03Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=980b8bc01938c8bcc9742c1051f64b5f0ed178ac'/>
<id>urn:sha1:980b8bc01938c8bcc9742c1051f64b5f0ed178ac</id>
<content type='text'>
Use the max mappable GPA via GuestPhysBits advertised by KVM to calculate
max_gfn. Currently some selftests (e.g. access_tracking_perf_test,
dirty_log_test...) add RAM regions close to max_gfn, so guest may access
GPA beyond its mappable range and cause infinite loop.

Adjust max_gfn in vm_compute_max_gfn() since x86 selftests already
overrides vm_compute_max_gfn() specifically to deal with goofy edge cases.

Reported-by: Yi Lai &lt;yi1.lai@intel.com&gt;
Signed-off-by: Tao Su &lt;tao1.su@linux.intel.com&gt;
Tested-by: Yi Lai &lt;yi1.lai@intel.com&gt;
Reviewed-by: Xiaoyao Li &lt;xiaoyao.li@intel.com&gt;
Link: https://lore.kernel.org/r/20240513014003.104593-1-tao1.su@linux.intel.com
[sean: tweak name, add comment and sanity check]
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>KVM: selftests: Init IDT and exception handlers for all VMs/vCPUs on x86</title>
<updated>2024-04-29T19:55:15Z</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2024-03-14T23:26:29Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=c1b9793b45d521767efdb6ab26008cabd0473ea9'/>
<id>urn:sha1:c1b9793b45d521767efdb6ab26008cabd0473ea9</id>
<content type='text'>
Initialize the IDT and exception handlers for all non-barebones VMs and
vCPUs on x86.  Forcing tests to manually configure the IDT just to save
8KiB of memory is a terrible tradeoff, and also leads to weird tests
(multiple tests have deliberately relied on shutdown to indicate success),
and hard-to-debug failures, e.g. instead of a precise unexpected exception
failure, tests see only shutdown.

Reviewed-by: Ackerley Tng &lt;ackerleytng@google.com&gt;
Link: https://lore.kernel.org/r/20240314232637.2538648-11-seanjc@google.com
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>Revert "kvm: selftests: move base kvm_util.h declarations to kvm_util_base.h"</title>
<updated>2024-04-29T19:54:13Z</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2024-03-14T23:26:20Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=2b7deea3ec7c81a92d4c17751d3bcd780d065ae4'/>
<id>urn:sha1:2b7deea3ec7c81a92d4c17751d3bcd780d065ae4</id>
<content type='text'>
Effectively revert the movement of code from kvm_util.h =&gt; kvm_util_base.h,
as the TL;DR of the justification for the move was to avoid #idefs and/or
circular dependencies between what ended up being ucall_common.h and what
was (and now again, is), kvm_util.h.

But avoiding #ifdef and circular includes is trivial: don't do that.  The
cost of removing kvm_util_base.h is a few extra includes of ucall_common.h,
but that cost is practically nothing.  On the other hand, having a "base"
version of a header that is really just the header itself is confusing,
and makes it weird/hard to choose names for headers that actually are
"base" headers, e.g. to hold core KVM selftests typedefs.

For all intents and purposes, this reverts commit
7d9a662ed9f0403e7b94940dceb81552b8edb931.

Reviewed-by: Ackerley Tng &lt;ackerleytng@google.com&gt;
Link: https://lore.kernel.org/r/20240314232637.2538648-2-seanjc@google.com
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
</content>
</entry>
<entry>
<title>selftests: kvm: switch to using KVM_X86_*_VM</title>
<updated>2024-04-11T17:08:27Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2024-04-04T12:13:25Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=d18c8648166e34d93b9d4a48e975bb24514d4a16'/>
<id>urn:sha1:d18c8648166e34d93b9d4a48e975bb24514d4a16</id>
<content type='text'>
This removes the concept of "subtypes", instead letting the tests use proper
VM types that were recently added.  While the sev_init_vm() and sev_es_init_vm()
are still able to operate with the legacy KVM_SEV_INIT and KVM_SEV_ES_INIT
ioctls, this is limited to VMs that are created manually with
vm_create_barebones().

Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Message-ID: &lt;20240404121327.3107131-16-pbonzini@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-x86-pvunhalt-6.9' of https://github.com/kvm-x86/linux into HEAD</title>
<updated>2024-03-18T23:19:08Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2024-03-18T23:19:08Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=0d1756482e66f326eb65fe08eed24ce2efabb168'/>
<id>urn:sha1:0d1756482e66f326eb65fe08eed24ce2efabb168</id>
<content type='text'>
Fix a bug in KVM_SET_CPUID{2,} where KVM looks at the wrong CPUID entries (old
vs. new) and ultimately neglects to clear PV_UNHALT from vCPUs with HLT-exiting
disabled.
</content>
</entry>
<entry>
<title>Merge tag 'kvm-x86-pmu-6.9' of https://github.com/kvm-x86/linux into HEAD</title>
<updated>2024-03-11T14:41:09Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2024-03-11T14:41:09Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=e9025cdd8c5c17e97949423856aced1d6f31c62f'/>
<id>urn:sha1:e9025cdd8c5c17e97949423856aced1d6f31c62f</id>
<content type='text'>
KVM x86 PMU changes for 6.9:

 - Fix several bugs where KVM speciously prevents the guest from utilizing
   fixed counters and architectural event encodings based on whether or not
   guest CPUID reports support for the _architectural_ encoding.

 - Fix a variety of bugs in KVM's emulation of RDPMC, e.g. for "fast" reads,
   priority of VMX interception vs #GP, PMC types in architectural PMUs, etc.

 - Add a selftest to verify KVM correctly emulates RDMPC, counter availability,
   and a variety of other PMC-related behaviors that depend on guest CPUID,
   i.e. are difficult to validate via KVM-Unit-Tests.

 - Zero out PMU metadata on AMD if the virtual PMU is disabled to avoid wasting
   cycles, e.g. when checking if a PMC event needs to be synthesized when
   skipping an instruction.

 - Optimize triggering of emulated events, e.g. for "count instructions" events
   when skipping an instruction, which yields a ~10% performance improvement in
   VM-Exit microbenchmarks when a vPMU is exposed to the guest.

 - Tighten the check for "PMI in guest" to reduce false positives if an NMI
   arrives in the host while KVM is handling an IRQ VM-Exit.
</content>
</entry>
</feed>
