- 18 May, 2020 2 commits
-
-
Roman Bolshakov authored
The tests can be run if Hypervisor.framework API is available: https://developer.apple.com/documentation/hypervisor?language=objc#1676667 Cc: Cameron Esfahani <dirty@apple.com> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Cameron Esfahani <dirty@apple.com> Message-Id: <20200320145541.38578-2-r.bolshakov@yadro.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Roman Bolshakov authored
If interrupts are disabled, STI is inhibiting interrupts for the instruction following it. If STI is followed by HLT, the CPU is going to handle all pending or new interrupts as soon as HLT is executed. Test if emulator properly clears inhibition state and allows the scenario outlined above. Cc: Cameron Esfahani <dirty@apple.com> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200329071125.79253-1-r.bolshakov@yadro.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 09 May, 2020 3 commits
-
-
Paolo Bonzini authored
This test is currently broken, but it passes under QEMU. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Jim Mattson authored
When the VMX-preemption timer is activated, code executing in VMX non-root operation should never be able to record a TSC value beyond the deadline imposed by adding the scaled VMX-preemption timer value to the first TSC value observed by the guest after VM-entry. Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Message-Id: <20200508203938.88508-1-jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Cathy Avery authored
Test V_IRQ injection from L1 to L2 with V_TPR less than or greater than V_INTR_PRIO. Also test VINTR intercept with differing V_TPR and V_INTR_PRIO. Signed-off-by:
Cathy Avery <cavery@redhat.com> Message-Id: <20200509111622.2184-1-cavery@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 06 May, 2020 1 commit
-
-
Cathy Avery authored
Signed-off-by:
Cathy Avery <cavery@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 05 May, 2020 1 commit
-
-
Paolo Bonzini authored
Results are undefined if xAPIC/x2APIC mode is not homogeneous on all processors. So far things seemed to have mostly worked, but if you end up calling xapic_icr_write from an x2APIC-mode processor the write is eaten and the IPI is not delivered. Reported-by:
Cathy Avery <cavery@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 04 May, 2020 6 commits
-
-
https://github.com/davidhildenbrand/kvm-unit-testsPaolo Bonzini authored
New maintainer, reviewer, and cc list. New STSI test. Lots of minor fixes and cleanups
-
Cathy Avery authored
The last test does not return vmmcall on fail resulting in passing the entire test. Signed-off-by:
Cathy Avery <cavery@redhat.com> Message-Id: <20200428184100.5426-1-cavery@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Squish the "address" stuffed into SYSENTER_EIP/ESP into an unsigned long so as to drop bits 63:32 on 32-bit builds. VMX diverges from bare metal in the sense that the associated VMCS fields are natural width fields, whereas the actual MSRs hold 64-bit values, even on CPUs that don't support 64-bit mode. This causes the tests to fail if bits 63:32 are non-zero and a VM-Exit/VM-Enter occurs on and/or between WRMSR/RDMSR, e.g. when running the tests in L1 or deeper. Don't bother trying to actually test that bits 63:32 are dropped, the behavior depends on the (virtual) CPU capabilities, not the build, and the behavior is specific to VMX as both SVM and bare metal preserve the full 64-bit values. And because practically no one cares about 32-bit KVM, let alone an obscure architectural quirk that doesn't affect real world kernels. Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200428231135.12903-1-sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Assert that vmcs.EXIT_QUALIFICATION contains the correct failure code on failed VM-Enter due to invalid guest state. Hardcode the expected code to the default code, '0', rather than passing in the expected code to minimize churn and boilerplate code, which works for all existing tests. Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200424174025.1379-1-sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Make test_ioapic_physical_destination_mode() depending on having at least two CPUs as it sets ->dest_id to '1', i.e. expects CPU0 and CPU1 to exist. This analysis is backed up by the fact that the test was originally gated by cpu_count() > 1. Fixes: dcf27dc5 ("x86: Fix the logical destination mode test") Cc: Nitesh Narayan Lal <nitesh@redhat.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200423195050.26310-1-sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Simon Smith authored
This commit adds new unit tests for commit a4d956b93904 ("KVM: nVMX: vmread should not set rflags to specify success in case of #PF") The two new tests force a vmread and a vmwrite on an unmapped address to cause a #PF and verify that the low byte of %rflags is preserved and that %rip is not advanced. The commit fixed a bug in vmread, but we include a test for vmwrite as well for completeness. Before the aforementioned commit, the ALU flags would be incorrectly cleared and %rip would be advanced (for vmread). Signed-off-by:
Simon Smith <brigidsmith@google.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Reviewed-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Reviewed-by:
Oliver Upton <oupton@google.com> Message-Id: <20200420175834.258122-1-brigidsmith@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 30 Apr, 2020 8 commits
-
-
Janosch Frank authored
Seems like I uppercased the whole region instead of only the ULs when I added those definitions. Let's make the x lowercase again. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-11-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Let's make sure we can restart a cpu that is already running. Restarting it if it is stopped is implicitely tested by the the other restart calls in the smp test. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-10-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Up to now we ignored the psw mask and only used the psw address when bringing up a new cpu. For DAT we need to also load the mask, so let's do that. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-8-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Now that we have a loop which is executed after we return from the main function of a secondary cpu, we can remove the surplus loops. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Acked-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-7-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Up to now a secondary cpu could have returned from the function it was executing and ending up somewhere in cstart64.S. This was mostly circumvented by an endless loop in the function that it executed. Let's add a loop to the end of the cpu setup, so we don't have to rely on added loops in the tests. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20200429143518.1360468-6-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Local interrupts (external and emergency call) should be cleared after any cpu reset. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20200429143518.1360468-5-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Let's also test the stop portion of the "stop and store status" sigp order. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-4-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Let's dirty the fpc, before we test if the initial reset sets it to 0. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200429143518.1360468-3-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
- 24 Apr, 2020 9 commits
-
-
Janosch Frank authored
All CRs are set to 0 and CRs 0 and 14 are set to pre-defined values, so we also need to test 1-13 and 15 for 0. And while we're at it, let's also set some values to cr 1, 7 and 13, so we can actually be sure that they will be zeroed. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200424093356.11931-1-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Andrew Jones authored
Signed-off-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Message-Id: <20200403094015.506838-1-drjones@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Christian Borntraeger authored
Two minimal tests: - our own CPU should be running when we check ourselves - a CPU should at least have some times with a not running indication. To speed things up we stop CPU1 Also rename smp_cpu_running to smp_sense_running_status. Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200402154441.13063-1-borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
STFLE operates on doublewords, not bytes. Passing in "256" resulted in some ignored bits getting set. Not bad, but also not clean. Let's just convert our stfle handling code to operate on doublewords. Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Message-Id: <20200401163305.31550-1-david@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Christian Borntraeger authored
On s390x hosts with a single CPU, the smp test case hangs (loops). The check if our restart has finished is wrong. Sigp sense running status checks if the CPU is currently backed by a real CPU. This means that on single CPU hosts a sigp sense running will never claim that a target is running. We need to check for not being stopped instead. Reviewed-by:
Janosch Frank <frankja@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200330084911.34248-2-borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Janosch Frank authored
Subcode 3.2.2 is handled by KVM/QEMU and should therefore be tested a bit more thoroughly. In this test we set a custom name and uuid through the QEMU command line. Both parameters will be passed to the guest on a stsi subcode 3.2.2 call and will then be checked. We also compare the configured cpu numbers against the smp reported numbers and if the reserved + configured add up to the total number reported. Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20200331071456.3302-1-frankja@linux.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Cornelia Huck authored
It makes sense to cc: patches there as well. Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20200324121722.9776-3-cohuck@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Cornelia Huck authored
Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Acked-by:
Janosch Frank <frankja@linux.ibm.com> Message-Id: <20200324121722.9776-2-cohuck@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Thomas Huth authored
Both, David and I, often do not have as much spare time for the kvm-unit-tests as we would like to have, so we could use a little bit of additional help here. Janosch did some excellent work for the s390x kvm-unit-tests in the past months and is listed as reviewer for these patches since quite a while already, so he's a very well suited for the maintainer job here, too. Signed-off-by:
Thomas Huth <thuth@redhat.com> Acked-by:
Janosch Frank <frankja@de.ibm.com> Acked-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200205101935.19219-1-thuth@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
- 23 Apr, 2020 6 commits
-
-
Paolo Bonzini authored
On AMD, the guest is not woken up from HLT by the interrupt or NMI vmexits. Therefore we have to fix up the RIP manually. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Enhance test_cr3_targets() to verify that attempting to write CR3-target value fields beyond the reported number of supported targets fails. Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200416162814.32065-1-sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Otherwise, the exc_inject fails if passed first on the command line. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Jim Mattson authored
Ensure that the delivery of a "VMX-preemption timer expired" VM-exit doesn't disrupt single-stepping in the guest. Note that passing this test doesn't ensure correctness. Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Oliver Upton <oupton@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Message-Id: <20200414001026.50051-2-jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Jim Mattson authored
Verify that both injected events and debug traps that result from pending debug exceptions take precedence over a "VMX-preemption timer expired" VM-exit resulting from a zero-valued VMX-preemption timer. Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Oliver Upton <oupton@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Message-Id: <20200414001026.50051-1-jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Mohammed Gamal authored
This extends the access tests to also test for reserved bits in guest physical addresses. Signed-off-by:
Mohammed Gamal <mgamal@redhat.com> Message-Id: <20200423103623.431206-1-mgamal@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 21 Apr, 2020 1 commit
-
-
Krish Sadhukhan authored
According to section "Canonicalization and Consistency Checks" in APM vol. 2, the following guest state is illegal: "CR0[63:32] are not zero." Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200420225825.3184-2-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 17 Apr, 2020 1 commit
-
-
Oliver Upton authored
SDM 26.6.2 describes how the VM-entry interruption-information field may be configured to inject an MTF VM-exit upon VM-entry. Ensure that an MTF VM-exit occurs when the VM-entry interruption-information field is configured appropriately by the host. Signed-off-by:
Oliver Upton <oupton@google.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Reviewed-by: Peter Shier<pshier@google.com> Message-Id: <20200414214634.126508-2-oupton@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 16 Apr, 2020 2 commits
-
-
Krish Sadhukhan authored
According to section "Canonicalization and Consistency Checks" in APM vol. 2, the following guest state combination is illegal: "CR0.CD is zero and CR0.NW is set" Signed-off-by:
Krish Sadhukhan <krish.sadhukhan@oracle.com> Message-Id: <20200409205035.16830-4-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: <20200409205035.16830-3-krish.sadhukhan@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-