- Jul 31, 2020
-
-
Paolo Bonzini authored
-
- Jul 30, 2020
-
-
Paolo Bonzini authored
Switching to gitlab. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 10, 2020
-
-
Nadav Amit authored
While there is a feature to limit RAM memory, we should also be able to limit the maximum RAM address. Specifically, svm can only work when the maximum RAM address is lower than 4G, as it does not map the rest of the memory into the NPT. Allow to do so using the firmware, when in fact the expected use-case is to provide this infomation on bare-metal using the MEMLIMIT parameter in initrd. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200710183320.27266-5-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
Recent changes cause end_of_memory to be disregarded in 32-bit. Remove the dead writes to it. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200710183320.27266-4-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
On nested page-faults due to write-protect or reserved bits, the present-bit in EXITINFO1 is set, as confirmed on bare-metal. Set the expected result accordingly. This indicates that KVM has a bug. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200710183320.27266-3-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
The BIOS might leave some bits set in CR4; for example, CR4.DE=1 would cause the SVM test for the DR intercept to fail, because DR4/DR5 can only be written when CR4.DE is clear, and otherwise trigger a #GP exception. Reported-by:
Nadav Amit <namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 08, 2020
-
-
Krish Sadhukhan authored
According to section "Canonicalization and Consistency Checks" in APM vol. 2, the following guest state is illegal: "Any MBZ bit of CR3 is set." "Any MBZ bit of CR4 is set." Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <1594168797-29444-4-git-send-email-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
r15 is used by ASM_VMRUN_CMD, so we need to mark it as clobbered. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 06, 2020
-
-
Claudio Imbrenda authored
Allow allocating aligned virtual memory with alignment larger than only one page. Add a check that the backing pages were actually allocated. Export the alloc_vpages_aligned function to allow users to allocate non-backed aligned virtual addresses. Signed-off-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Message-Id: <20200706164324.81123-5-imbrenda@linux.ibm.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Claudio Imbrenda authored
The functions get_order and is_power_of_2 are simple and should probably be in a header, like similar simple functions in bitops.h Since they concern bit manipulation, the logical place for them is in bitops.h Signed-off-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Message-Id: <20200706164324.81123-4-imbrenda@linux.ibm.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Claudio Imbrenda authored
For size parameters, size_t is probably semantically more appropriate than unsigned long (although they map to the same value). For order, unsigned long is just too big. Also, get_order returns an unsigned int anyway. Signed-off-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Message-Id: <20200706164324.81123-3-imbrenda@linux.ibm.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Claudio Imbrenda authored
Since size is of type size_t, size >> PAGE_SHIFT might still be too big for a normal unsigned int. Signed-off-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Message-Id: <20200706164324.81123-2-imbrenda@linux.ibm.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
The VMX tests are 64-bit only, so checking the architecture is unnecessary. Also, if the tests supported 32-bits environments the #ifdef would probably go in test_canonical. Reported-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Krish Sadhukhan authored
According to section "Checks on Guest Descriptor-Table Registers" in Intel SDM vol 3C, the following checks are performed on the Guest Descriptor-Table Registers on vmentry of nested guests: - Bits 31:16 of each limit field must be 0. Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200523002603.32450-4-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Krish Sadhukhan authored
According to section "Checks on Guest Descriptor-Table Registers" in Intel SDM vol 3C, the following check is performed on the Guest Descriptor-Table Registers on vmentry of nested guests: - On processors that support Intel 64 architecture, the base-address fields must contain canonical addresses. Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200523002603.32450-2-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Krish Sadhukhan authored
Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200522221954.32131-5-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 03, 2020
-
-
Sean Christopherson authored
Add a test to verify that KVM correctly injects a #GP if the guest attempts to toggle CR4.LA57 while 64-bit mode is active. Use two versions of the toggling, one to toggle only LA57 and a second to toggle PSE in addition to LA57. KVM doesn't intercept LA57, i.e. toggling only LA57 effectively tests the CPU, not KVM. Use PSE as the whipping boy as it will not trigger a #GP on its own, is universally available, is ignored in 64-bit mode, and most importantly is trapped by KVM. Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200703021903.5683-1-sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 02, 2020
-
-
Nadav Amit authored
In some setups serial output from the real-mode tests is corrupted. I do not know the serial port initialization code well, but the protected mode initialization code is different than the real-mode code. Using the protected mode serial port initialization fixes the problem. Keeping the tradition of code duplication between real-mode and protected mode, this patch copies the missing initialization into real-mode serial port initialization. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200701193045.31247-1-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 01, 2020
-
-
Krish Sadhukhan authored
kvm-unit-tests: nSVM: Test that DR6[63:32], DR7[63:32] and EFER reserved bits are not set on vmrun of nested guests According to section "Canonicalization and Consistency Checks" in APM vol. 2 the following guest state is illegal: "DR6[63:32] are not zero." "DR7[63:32] are not zero." "Any MBZ bit of EFER is set." Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200522221954.32131-4-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Snapshot the delta of the last run and display it in the report if the test fails. Abort the run loop as soon as the threshold is reached so that the displayed delta is guaranteed to a failed delta. Displaying the delta helps triage failures, e.g. is my system completely broken or did I get unlucky, and aborting the loop early saves 99900 runs when the system is indeed broken. Cc: Nadav Amit <nadav.amit@gmail.com> Cc: Aaron Lewis <aaronlewis@google.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200124234608.10754-1-sean.j.christopherson@intel.com> Reviewed-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Reviewed-by:
Aaron Lewis <aaronlewis@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
exc_inject advances the ripon every stage, so it can do so 3 times, but there are only 2 vmmcall instructions that the guest runs. So, if a failure happens on the last test, there is no vmmcall instruction to trigger an exit. Advance the rip only in the two stages in which vmmcall is expected to run. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200630094516.22983-6-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
According to AMD manual bit 8 of the PDPE is not reserved, but it is in PML4E. Reported-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200630094516.22983-5-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
Several svm tests change PTEs but do not flush the TLB. To avoid messing around or encountering new bugs in the future, flush the TLB on every test. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200630094516.22983-4-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
MSR_IA32_TSC_ADJUST may be supported by KVM on AMD machines, but it does not show on AMD manual. Check CPUID to see if it supported before running the relevant tests. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200630094516.22983-3-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
boot_idt is now a symbol. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200630094516.22983-2-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Thomas Huth authored
Thank to the recent fixes, there are now quite a lot of additional 32-bit x86 tests that we can run in the CI. And thanks to the update to Fedora 32 (that introduced a newer version of QEMU), there are now also some additional tests that we can run with TCG for the other architectures. Note that for arm/aarch64, we now also set the MAX_SMP to be able to run SMP-tests with TCG in the single-threaded CI containers, too. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20200701100615.7975-1-thuth@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
When you currently run ./run_tests.sh ioapic-split the kvm-unit-tests run scripts do not only execute the "ioapic-split" test, but also the "ioapic" test, which is quite surprising. This happens because we use "grep -w" for checking whether a test should be run or not. Because "grep -w" does not consider the "-" character as part of a word, "ioapic" successfully matches against "ioapic-split". To fix the issue, use spaces as the only delimiter when running "grep", removing the problematic "-w" flag from the invocation. While at it, add "-F" to avoid unintended use of regular expression metacharacters. Reported-by:
Thomas Huth <thuth@redhat.com> Tested-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 29, 2020
-
-
Nadav Amit authored
Some mask computation are using long constants instead of long long constants, which causes test failures on x86-32. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200619193909.18949-1-namit@vmware.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 26, 2020
-
-
Nadav Amit authored
Running lss with some random descriptor and then performing pop does not work so well. Use mov instructions instead of push/pop pair. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200626092333.2830-4-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
For systems without emulated devices (e.g., bare-metal), use halt-loop when exiting the realmode test. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200626092333.2830-3-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
The realmode test does not initialize the IDTR, assuming that its base is zero and its limit 0x3ff. Initialize it, as the bootloader might not set it as such. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200626092333.2830-2-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Right now only addresses up to the highest RAM memory address are are mapped 1:1 into the 32-bit page tables, but this also excludes ACPI-reserved areas that are higher than the highest RAM memory address. Depending on the memory layout, this may prevent the tests from accessing the ACPI tables after setup_vm. Unconditionally including the bottom 2G of memory fixes that. We do rely on the ACPI tables being in the first 2GB of memory, which is not necessarily true on bare metal; fixing that requires adding calls to something like Linux's kmap/kunmap. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 25, 2020
-
-
Paolo Bonzini authored
The base of the percpu area is stored in the %gs base, and writing to %gs destroys it. Move setup_segments earlier, before the %gs base is written, and keep setup_percpu_area close so that the base is updated close to the selector. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
smp_stacktop in 32-bit is fixed to some magic address. Use the address of the memory that was reserved for the stack instead. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200624203602.44659-1-namit@vmware.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Since setup_multiboot has a C calling convention, the stack pointer must be adjusted after the call. Without this change, the bottom of the percpu area would be 4 bytes below the bottom of the stack and overlap the top 4 bytes of CPU 1's stack. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Address 0 is also used for the SIPI vector (which is probably something worth changing as well), and now that we call setup_idt very early the SIPI vector overwrites the first few bytes of the IDT, and in particular the #DE handler. Fix this for both 32-bit and 64-bit, even though the different form of the descriptors meant that only 32-bit showed a failure. Reported-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 24, 2020
-
-
Vitaly Kuznetsov authored
'nmi_hlt' test returns somewhat weird result: ... PASS: direct NMI + hlt PASS: NMI intercept while running guest PASS: intercepted NMI + hlt PASS: nmi_hlt SUMMARY: 4 tests, 1 unexpected failures Trying to investigate where the failure is coming from I was tweaking the code around and with tiny meaningless changes I was able to observe #PF, #GP, #UD and other 'interesting' results. Compiler optimization flags also change the outcome so there's obviously a corruption somewhere. Adding a meaningless 'nop' to the second 'asm volatile ("hlt");' in nmi_hlt_test() saves the day so it seems we erroneously advance RIP twice, the advancement in nmi_hlt_finished() is not needed. The outcome, however, contradicts with the commit message in 7e7aa86f ("SVM: move guest past HLT"). With that commit reverted, all tests seem to pass but I'm not sure what issue the commit was trying to fix, thus RFC. This reverts commit 7e7aa86f. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200623082711.803916-1-vkuznets@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
Currently, the BSP's segment selectors are not initialized in 32-bit (cstart.S). As a result the tests implicitly rely on the segment selector values that are set by the BIOS. If this assumption is not kept, the task-switch test fails. Fix it by initializing them. Signed-off-by:
Nadav Amit <namit@vmware.com> Message-Id: <20200623084132.36213-1-namit@vmware.com> Reviewed-by:
Jim Mattson <jmattson@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Vitaly Kuznetsov authored
Hyper-V TSC page clocksource is TSC based so it requires host to use TSC for clocksource. While TSC is more or less standard for x86 hardware nowadays, when kvm-unit-tests are run in a VM the clocksource tends to be different (e.g. kvm-clock). Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200617152139.402827-1-vkuznets@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 23, 2020
-
-
https://gitlab.com/huth/kvm-unit-testsPaolo Bonzini authored
* Lots of CI-related fixes and improvements * Update the gitlab-CI to Fedora 32 * Test compilation with Clang
-