- 28 Aug, 2023 10 commits
-
-
Steffen Eiden authored
Introduces a function to check the existence of an UV feature. Refactor feature bit checks to use the new function. Signed-off-by:
Steffen Eiden <seiden@linux.ibm.com> Reviewed-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Signed-off-by:
Michael Mueller <mimu@linux.ibm.com> Link: https://lore.kernel.org/r/20230815151415.379760-3-seiden@linux.ibm.com Message-Id: <20230815151415.379760-3-seiden@linux.ibm.com>
-
Viktor Mihajlovski authored
Destroy configuration fast may return with RC 0x104 if there are still bound APQNs in the configuration. The final cleanup will occur with the standard destroy configuration UVC as at this point in time all APQNs have been reset and thus unbound. Therefore, don't warn if RC 0x104 is reported. Signed-off-by:
Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by:
-
Janosch Frank authored
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.
-
Ilya Leoshkevich authored
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:
Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20230725143857.228626-7-iii@linux.ibm.com> Signed-off-by:
-
Ilya Leoshkevich authored
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 authored
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:
-
Ilya Leoshkevich authored
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:
-
Ilya Leoshkevich authored
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:
-
Ilya Leoshkevich authored
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:
-
Janosch Frank authored
Provide an immutable point in kvm-x86/selftests so that the guest printf() support can be merged into other architectures' trees.
-
- 18 Aug, 2023 12 commits
-
-
Tony Krowiak authored
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:
Tony Krowiak <akrowiak@linux.ibm.com> Acked-by:
Halil Pasic <pasic@linux.ibm.com> Tested-by:
Heiko Carstens <hca@linux.ibm.com>
-
Tony Krowiak authored
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 authored
Export the uv_pin_shared function so that it can be called from other modules that carry a GPL-compatible license. Signed-off-by:
-
Tony Krowiak authored
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:
Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by:
-
Tony Krowiak authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 17 Aug, 2023 6 commits
-
-
Jinrong Liang authored
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.comSigned-off-by:
Sean Christopherson <seanjc@google.com>
-
Jinrong Liang authored
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:
Isaku Yamahata <isaku.yamahata@intel.com> Link: https://lore.kernel.org/r/20230810090945.16053-6-cloudliang@tencent.comSigned-off-by:
-
Jinrong Liang authored
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 authored
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: -
Jinrong Liang authored
None of the callers consume remove_event(), and it incorrectly implies that the incoming filter isn't modified. Drop the return. Suggested-by:
-
Jinrong Liang authored
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:
-
- 02 Aug, 2023 12 commits
-
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
Convert x86's XCR0 vs. CPUID test to use printf-based guest asserts. Link: https://lore.kernel.org/r/20230729003643.1053367-32-seanjc@google.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
Convert x86's userspace I/O test to use printf-based guest asserts. Link: https://lore.kernel.org/r/20230729003643.1053367-30-seanjc@google.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
Sean Christopherson authored
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.comSigned-off-by:
-
