summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-28Merge remote-tracking branch 'vfio-ap' into nextJanosch Frank
The Secure Execution AP support makes it possible for SE VMs to securely use APQNs without a third party being able to snoop IO. VMs first bind to an APQN to securely attach it and granting protected key crypto function access. Afterwards they can associate the APQN which grants them clear key crypto function access. Once bound the APQNs are not accessible to the host until a reset is performed. The vfio-ap patches being merged here provide the base hypervisor Secure Execution / Protected Virtualization AP support. This includes proper handling of APQNs that are securely attached to a SE/PV guest especially regarding resets.
2023-08-28KVM: s390: selftests: Add selftest for single-steppingIlya Leoshkevich
Test different variations of single-stepping into interrupts: - SVC and PGM interrupts; - Interrupts generated by ISKE; - Interrupts generated by instructions emulated by KVM; - Interrupts generated by instructions emulated by userspace. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-7-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> [frankja@de.igm.com: s/ASSERT_EQ/TEST_ASSERT_EQ/ because function was renamed in the selftest printf series] Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28KVM: s390: interrupt: Fix single-stepping keyless mode exitsIlya Leoshkevich
kvm_s390_skey_check_enable() does not emulate any instructions, rather, it clears CPUSTAT_KSS and arranges the instruction that caused the exit (e.g., ISKE, SSKE, RRBE or LPSWE with a keyed PSW) to run again. Therefore, skip the PER check and let the instruction execution happen. Otherwise, a debugger will see two single-step events on the same instruction. Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-6-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28KVM: s390: interrupt: Fix single-stepping userspace-emulated instructionsIlya Leoshkevich
Single-stepping a userspace-emulated instruction that generates an interrupt causes GDB to land on the instruction following it instead of the respective interrupt handler. The reason is that after arranging a KVM_EXIT_S390_SIEIC exit, kvm_handle_sie_intercept() calls kvm_s390_handle_per_ifetch_icpt(), which sets KVM_GUESTDBG_EXIT_PENDING. This bit, however, is not processed immediately, but rather persists until the next ioctl(), causing a spurious single-step exit. Fix by clearing this bit in ioctl(). Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-5-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28KVM: s390: interrupt: Fix single-stepping kernel-emulated instructionsIlya Leoshkevich
Single-stepping a kernel-emulated instruction that generates an interrupt causes GDB to land on the instruction following it instead of the respective interrupt handler. The reason is that kvm_handle_sie_intercept(), after injecting the interrupt, also processes the PER event and arranges a KVM_SINGLESTEP exit. The interrupt is not yet delivered, however, so the userspace sees the next instruction. Fix by avoiding the KVM_SINGLESTEP exit when there is a pending interrupt. The next __vcpu_run() loop iteration will arrange a KVM_SINGLESTEP exit after delivering the interrupt. Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-4-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28KVM: s390: interrupt: Fix single-stepping into program interrupt handlersIlya Leoshkevich
Currently, after single-stepping an instruction that generates a specification exception, GDB ends up on the instruction immediately following it. The reason is that vcpu_post_run() injects the interrupt and sets KVM_GUESTDBG_EXIT_PENDING, causing a KVM_SINGLESTEP exit. The interrupt is not delivered, however, therefore userspace sees the address of the next instruction. Fix by letting the __vcpu_run() loop go into the next iteration, where vcpu_pre_run() delivers the interrupt and sets KVM_GUESTDBG_EXIT_PENDING. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20230725143857.228626-3-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28KVM: s390: interrupt: Fix single-stepping into interrupt handlersIlya Leoshkevich
After single-stepping an instruction that generates an interrupt, GDB ends up on the second instruction of the respective interrupt handler. The reason is that vcpu_pre_run() manually delivers the interrupt, and then __vcpu_run() runs the first handler instruction using the CPUSTAT_P flag. This causes a KVM_SINGLESTEP exit on the second handler instruction. Fix by delaying the KVM_SINGLESTEP exit until after the manual interrupt delivery. Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-2-iii@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-08-28Merge tag 'kvm-x86-selftests-immutable-6.6' into nextJanosch Frank
Provide an immutable point in kvm-x86/selftests so that the guest printf() support can be merged into other architectures' trees.
2023-08-18s390/vfio-ap: make sure nib is sharedTony Krowiak
Since the NIB is visible by HW, KVM and the (PV) guest it needs to be in non-secure or secure but shared storage. Return code 6 is used to indicate to a PV guest that its NIB would be on secure, unshared storage and therefore the NIB address is invalid. Unfortunately we have no easy way to check if a page is unshared after vfio_pin_pages() since it will automatically export an unshared page if the UV pin shared call did not succeed due to a page being in unshared state. Therefore we use the fact that UV pinning it a second time is a nop but trying to pin an exported page is an error (0x102). If we encounter this error, we do a vfio unpin and import the page again, since vfio_pin_pages() exported it. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-13-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18KVM: s390: export kvm_s390_pv*_is_protected functionsTony Krowiak
Export the kvm_s390_pv_is_protected and kvm_s390_pv_cpu_is_protected functions so that they can be called from other modules that carry a GPL-compatible license. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-12-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/uv: export uv_pin_shared for direct usageJanosch Frank
Export the uv_pin_shared function so that it can be called from other modules that carry a GPL-compatible license. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-11-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: check for TAPQ response codes 0x35 and 0x36Tony Krowiak
Check for response codes 0x35 and 0x36 which are asynchronous return codes indicating a failure of the guest to associate a secret with a queue. Since there can be no interaction with this queue from the guest (i.e., the vcpus are out of SIE for hot unplug, the guest is being shut down or an emulated subsystem reset of the guest is taking place), let's go ahead and re-issue the ZAPQ to reset and zeroize the queue. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-10-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: handle queue state change in progress on resetTony Krowiak
A new APQSW response code (0xA) indicating the designated queue is in the process of being bound or associated to a configuration may be returned from the PQAP(ZAPQ) command. This patch introduces code that will verify when the PQAP(ZAPQ) command can be re-issued after receiving response code 0xA. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-9-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: use work struct to verify queue resetTony Krowiak
Instead of waiting to verify that a queue is reset in the vfio_ap_mdev_reset_queue function, let's use a wait queue to check the the state of the reset. This way, when resetting all of the queues assigned to a matrix mdev, we don't have to wait for each queue to be reset before initiating a reset on the next queue to be reset. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Suggested-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-8-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: store entire AP queue status word with the queue objectTony Krowiak
Store the entire AP queue status word returned from the ZAPQ command with the struct vfio_ap_queue object instead of just the response code field. The other information contained in the status word is need by the apq_reset_check function to display a proper message to indicate that the vfio_ap driver is waiting for the ZAPQ to complete because the queue is not empty or IRQs are still enabled. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-7-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: remove upper limit on wait for queue reset to completeTony Krowiak
The architecture does not define an upper limit on how long a queue reset (RAPQ/ZAPQ) can take to complete. In order to ensure both the security requirements and prevent resource leakage and corruption in the hypervisor, it is necessary to remove the upper limit (200ms) the vfio_ap driver currently waits for a reset to complete. This, of course, may result in a hang which is a less than desirable user experience, but until a firmware solution is provided, this is a necessary evil. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-6-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: allow deconfigured queue to be passed through to a guestTony Krowiak
When a queue is reset, the status response code returned from the reset operation is stored in the reset_rc field of the vfio_ap_queue structure representing the queue being reset. This field is later used to decide whether the queue should be passed through to a guest. If the reset_rc field is a non-zero value, the queue will be filtered from the list of queues passed through. When an adapter is deconfigured, all queues associated with that adapter are reset. That being the case, it is not necessary to filter those queues; so, if the status response code returned from a reset operation indicates the queue is deconfigured, the reset_rc field of the vfio_ap_queue structure will be set to zero so it will be passed through (i.e., not filtered). Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-5-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: wait for response code 05 to clear on queue resetTony Krowiak
Response code 05, AP busy, is a valid response code for a ZAPQ or TAPQ. Instead of returning error -EIO when a ZAPQ fails with response code 05, let's wait until the queue is no longer busy and try the ZAPQ again. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-4-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: clean up irq resources if possibleTony Krowiak
The architecture does not specify whether interrupts are disabled as part of the asynchronous reset or upon return from the PQAP/ZAPQ instruction. If, however, PQAP/ZAPQ completes with APQSW response code 0 and the interrupt bit in the status word is also 0, we know the interrupts are disabled and we can go ahead and clean up the corresponding resources; otherwise, we must wait until the asynchronous reset has completed. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Suggested-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-3-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/vfio-ap: no need to check the 'E' and 'I' bits in APQSW after TAPQTony Krowiak
After a ZAPQ is executed to reset a queue, if the queue is not empty or interrupts are still enabled, the vfio_ap driver will wait for the reset operation to complete by repeatedly executing the TAPQ instruction and checking the 'E' and 'I' bits in the APQSW to verify that the queue is empty and interrupts are disabled. This is unnecessary because it is sufficient to check only the response code in the APQSW. If the reset is still in progress, the response code will be 02; however, if the reset has completed successfully, the response code will be 00. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-2-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-17KVM: selftests: Test gp event filters don't affect fixed event filtersJinrong Liang
Add a test to ensure that setting both generic and fixed performance event filters does not affect the consistency of the fixed event filter behavior in KVM. Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Link: https://lore.kernel.org/r/20230810090945.16053-7-cloudliang@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-17KVM: selftests: Test if event filter meets expectations on fixed countersJinrong Liang
Add tests to cover that pmu event_filter works as expected when it's applied to fixed performance counters, even if there is none fixed counter exists (e.g. Intel guest pmu version=1 or AMD guest). Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> Link: https://lore.kernel.org/r/20230810090945.16053-6-cloudliang@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-17KVM: selftests: Add test cases for unsupported PMU event filter input valuesJinrong Liang
Add test cases to verify the handling of unsupported input values for the PMU event filter. The tests cover unsupported "action" values, unsupported "flags" values, and unsupported "nevents" values. All these cases should return an error, as they are currently not supported by the filter. Furthermore, the tests also cover the case where setting non-existent fixed counters in the fixed bitmap does not fail. Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> Link: https://lore.kernel.org/r/20230810090945.16053-5-cloudliang@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-17KVM: selftests: Introduce "struct __kvm_pmu_event_filter" to manipulate filterJinrong Liang
Add custom "__kvm_pmu_event_filter" structure to improve pmu event filter settings. Simplifies event filter setup by organizing event filter parameters in a cleaner, more organized way. Alternatively, selftests could use a struct overlay ala vcpu_set_msr() to avoid dynamically allocating the array: struct { struct kvm_msrs header; struct kvm_msr_entry entry; } buffer = {}; memset(&buffer, 0, sizeof(buffer)); buffer.header.nmsrs = 1; buffer.entry.index = msr_index; buffer.entry.data = msr_value; but the extra layer added by the nested structs is counterproductive to writing efficient, clean code. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Link: https://lore.kernel.org/r/20230810090945.16053-4-cloudliang@tencent.com [sean: massage changelog to explain alternative] Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-17KVM: selftests: Drop the return of remove_event()Jinrong Liang
None of the callers consume remove_event(), and it incorrectly implies that the incoming filter isn't modified. Drop the return. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Link: https://lore.kernel.org/r/20230810090945.16053-3-cloudliang@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-17KVM: selftests: Add x86 properties for Intel PMU in processor.hJinrong Liang
Add x86 properties for Intel PMU so that tests don't have to manually retrieve the correct CPUID leaf+register, and so that the resulting code is self-documenting. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Link: https://lore.kernel.org/r/20230810090945.16053-2-cloudliang@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Use GUEST_FAIL() in ARM's arch timer helpersSean Christopherson
Use GUEST_FAIL() in ARM's arch timer helpers now that printf-based guest asserts are the default (and only) style of guest asserts, and say goodbye to the GUEST_ASSERT_1() alias. Link: https://lore.kernel.org/r/20230729003643.1053367-35-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Print out guest RIP on unhandled exceptionSean Christopherson
Use the newfanged printf-based guest assert framework to spit out the guest RIP when an unhandled exception is detected, which makes debugging such failures *much* easier. Link: https://lore.kernel.org/r/20230729003643.1053367-34-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Rip out old, param-based guest assert macrosSean Christopherson
Drop the param-based guest assert macros and enable the printf versions for all selftests. Note! This change can affect tests even if they don't use directly use guest asserts! E.g. via library code, or due to the compiler making different optimization decisions. Link: https://lore.kernel.org/r/20230729003643.1053367-33-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's XCR0 test to use printf-based guest assertsSean Christopherson
Convert x86's XCR0 vs. CPUID test to use printf-based guest asserts. Link: https://lore.kernel.org/r/20230729003643.1053367-32-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert VMX's PMU capabilities test to printf guest assertsSean Christopherson
Convert x86's VMX PMU capabilities test to use printf-based guest asserts. Opportunstically add a helper to do the WRMSR+assert so as to reduce the amount of copy+paste needed to spit out debug information. Link: https://lore.kernel.org/r/20230729003643.1053367-31-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the x86 userspace I/O test to printf guest assertSean Christopherson
Convert x86's userspace I/O test to use printf-based guest asserts. Link: https://lore.kernel.org/r/20230729003643.1053367-30-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's TSC MSRs test to use printf guest assertsSean Christopherson
Convert x86's TSC MSRs test, and it's liberal use of GUEST_ASSERT_EQ(), to use printf-based guest assert reporting. Link: https://lore.kernel.org/r/20230729003643.1053367-29-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the nSVM software interrupt test to printf guest assertsSean Christopherson
Convert x86's nested SVM software interrupt injection test to use printf- based guest asserts. Opportunistically use GUEST_ASSERT() and GUEST_FAIL() in a few locations to spit out more debug information. Link: https://lore.kernel.org/r/20230729003643.1053367-28-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's set BSP ID test to printf style guest assertsSean Christopherson
Convert the set_boot_cpu_id test to use printf-based guest asserts, specifically the EQ and NE variants. Link: https://lore.kernel.org/r/20230729003643.1053367-27-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's nested exceptions test to printf guest assertsSean Christopherson
Convert x86's nested exceptions test to printf-based guest asserts, and use REPORT_GUEST_ASSERT() instead of TEST_FAIL() so that output is formatted correctly. Link: https://lore.kernel.org/r/20230729003643.1053367-26-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the MONITOR/MWAIT test to use printf guest assertsSean Christopherson
Convert x86's MONITOR/MWAIT test to use printf-based guest asserts. Add a macro to handle reporting failures to reduce the amount of copy+paste needed for MONITOR vs. MWAIT. Link: https://lore.kernel.org/r/20230729003643.1053367-25-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's KVM paravirt test to printf style GUEST_ASSERTSean Christopherson
Convert x86's KVM paravirtualization test to use the printf-based GUEST_ASSERT_EQ(). Link: https://lore.kernel.org/r/20230729003643.1053367-24-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the Hyper-V feature test to printf style GUEST_ASSERTSean Christopherson
Convert x86's Hyper-V feature test to use print-based guest asserts. Opportunistically use the EQ and NE variants in a few places to capture additional information. Link: https://lore.kernel.org/r/20230729003643.1053367-23-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the Hyper-V extended hypercalls test to printf assertsSean Christopherson
Convert x86's Hyper-V extended hypercalls test to use printf-based GUEST_ASSERT_EQ(). Link: https://lore.kernel.org/r/20230729003643.1053367-22-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert x86's CPUID test to printf style GUEST_ASSERTSean Christopherson
Convert x86's CPUID test to use printf-based GUEST_ASSERT_EQ() so that the test prints out debug information. Note, the test previously used REPORT_GUEST_ASSERT_2(), but that was pointless because none of the guest-side code passed any parameters to the assert. Link: https://lore.kernel.org/r/20230729003643.1053367-21-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert steal_time test to printf style GUEST_ASSERTSean Christopherson
Convert the steal_time test to use printf-based GUEST_ASERT. Opportunistically use GUEST_ASSERT_EQ() and GUEST_ASSERT_NE() so that the test spits out debug information on failure. Link: https://lore.kernel.org/r/20230729003643.1053367-20-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert set_memory_region_test to printf-based GUEST_ASSERTSean Christopherson
Convert set_memory_region_test to print-based GUEST_ASSERT, using a combo of newfangled macros to report (hopefully) useful information. Link: https://lore.kernel.org/r/20230729003643.1053367-19-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert s390's tprot test to printf style GUEST_ASSERTSean Christopherson
Convert s390's tprot test to printf-based GUEST_ASSERT. Link: https://lore.kernel.org/r/20230729003643.1053367-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert s390's memop test to printf style GUEST_ASSERTSean Christopherson
Convert s390's memop test to printf-based GUEST_ASSERT, and opportunistically use GUEST_FAIL() to report invalid sizes. Link: https://lore.kernel.org/r/20230729003643.1053367-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert the memslot performance test to printf guest assertsSean Christopherson
Use the printf-based GUEST_ASSERT_EQ() in the memslot perf test instead of an half-baked open code version. Link: https://lore.kernel.org/r/20230729003643.1053367-16-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert ARM's vGIC IRQ test to printf style GUEST_ASSERTSean Christopherson
Use printf-based guest assert reporting in ARM's vGIC IRQ test. Note, this is not as innocuous as it looks! The printf-based version of GUEST_ASSERT_EQ() ensures the expressions are evaluated only once, whereas the old version did not! Link: https://lore.kernel.org/r/20230729003643.1053367-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert ARM's page fault test to printf style GUEST_ASSERTSean Christopherson
Use GUEST_FAIL() in ARM's page fault test to report unexpected faults. Link: https://lore.kernel.org/r/20230729003643.1053367-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert ARM's hypercalls test to printf style GUEST_ASSERTSean Christopherson
Convert ARM's hypercalls test to use printf-based GUEST_ASSERT(). Opportunistically use GUEST_FAIL() to complain about an unexpected stage. Link: https://lore.kernel.org/r/20230729003643.1053367-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-08-02KVM: selftests: Convert debug-exceptions to printf style GUEST_ASSERTSean Christopherson
Convert ARM's debug exceptions test to use printf-based GUEST_ASSERT(). Opportunistically Use GUEST_ASSERT_EQ() in guest_code_ss() so that the expected vs. actual values get printed out. Link: https://lore.kernel.org/r/20230729003643.1053367-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
generated by cgit (git 2.34.1) at 2025-09-29 09:41:13 +0000