- 13 Jul, 2022 7 commits
-
-
Claudio Imbrenda authored
Refactor s390_reset_acc so that it can be reused in upcoming patches. We don't want to hold all the locks used in a walk_page_range for too long, and the destroy page UVC does take some time to complete. Therefore we quickly gather the pages to destroy, and then destroy them without holding all the locks. The new refactored function optionally allows to return early without completing if a fatal signal is pending (and return and appropriate error code). Two wrappers are provided to call the new function. Signed-off-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Nico Boehr <nrb@linux.ibm.com> Link: https://lore.kernel.org/r/20220628135619.32410-5-imbrenda@linux.ibm.com Message-Id: <20220628135619.32410-5-imbrenda@linux.ibm.com> Signed-off-by:
-
Claudio Imbrenda authored
With upcoming patches, normal guests might touch secure pages. This patch extends the existing exception handler to convert the pages to non secure also when the exception is triggered by a normal guest. This can happen for example when a secure guest reboots; the first stage of a secure guest is non secure, and in general a secure guest can reboot into non-secure mode. If the secure memory of the previous boot has not been cleared up completely yet (which will be allowed to happen in an upcoming patch), a non-secure guest might touch secure memory, which will need to be handled properly. This means that gmap faults must be handled and not cause termination of the process. The handling is the same as userspace accesses, it's enough to translate the gmap address to a user address and then let the normal user fault code handle it. Signed-off-by:
-
Claudio Imbrenda authored
A secure storage violation is triggered when a protected guest tries to access secure memory that has been mapped erroneously, or that belongs to a different protected guest or to the ultravisor. With upcoming patches, protected guests will be able to trigger secure storage violations in normal operation. This happens for example if a protected guest is rebooted with deferred destroy enabled and the new guest is also protected. When the new protected guest touches pages that have not yet been destroyed, and thus are accounted to the previous protected guest, a secure storage violation is raised. This patch adds handling of secure storage violations for protected guests. This exception is handled by first trying to destroy the page, because it is expected to belong to a defunct protected guest where a destroy should be possible. Note that a secure page can only be destroyed if its protected VM does not have any CPUs, which only happens when the protected VM is being terminated. If that fails, a normal export of the page is attempted. This means that pages that trigger the exception will be made non-secure (in one way or another) before attempting to use them again for a different secure guest. Signed-off-by:
-
Claudio Imbrenda authored
Each secure guest must have a unique ASCE (address space control element); we must avoid that new guests use the same page for their ASCE, to avoid errors. Since the ASCE mostly consists of the address of the topmost page table (plus some flags), we must not return that memory to the pool unless the ASCE is no longer in use. Only a successful Destroy Secure Configuration UVC will make the ASCE reusable again. If the Destroy Configuration UVC fails, the ASCE cannot be reused for a secure guest (either for the ASCE or for other memory areas). To avoid a collision, it must not be used again. This is a permanent error and the page becomes in practice unusable, so we set it aside and leak it. On failure we already leak other memory that belongs to the ultravisor (i.e. the variable and base storage for a guest) and not leaking the topmost page table was an oversight. This error (and thus the leakage) should not happen unless the hardware is broken or KVM has some unknown serious bug. Signed-off-by:
-
Christian Borntraeger authored
z16 also provides facility 197 (The processor-activity-instrumentation extension 1). Let's add it to KVM. Signed-off-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Link: https://lore.kernel.org/r/20220711115108.6494-1-borntraeger@linux.ibm.comAcked-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
-
Bagas Sanjaya authored
Stephen Rothwell reported the htmldocs warning: Documentation/virt/kvm/api.rst:5959: WARNING: Title underline too short. 4.137 KVM_S390_ZPCI_OP -------------------- The warning is due to subheading underline on KVM_S390_ZPCI_OP section is short of 2 dashes. Extend the underline to fix the warning. Link: https://lore.kernel.org/linux-next/20220711205557.183c3b14@canb.auug.org.au/ Fixes: a0c4d1109d6cc5 ("KVM: s390: add KVM_S390_ZPCI_OP to manage guest zPCI devices") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Pierre Morel <pmorel@linux.ibm.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Matthew Rosato <mjrosato@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: kvm@vger.kernel.org Cc: linux-s390@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20220712092954.142027-4-bagasdotme@gmail.comSigned-off-by:
-
Christian Borntraeger authored
remove the duplicate includes. While at it sort the includes. Reported-by:
kernel test robot <yujie.liu@intel.com> Fixes: 73f91b00 ("KVM: s390: pci: enable host forwarding of Adapter Event Notifications") Signed-off-by:
-
- 11 Jul, 2022 24 commits
-
-
Steffen Eiden authored
We have information about the supported attestation header version and plaintext attestation flag bits. Let's expose it via the sysfs files. Signed-off-by:
Steffen Eiden <seiden@linux.ibm.com> Reviewed-by:
-
Jiang Jian authored
there is an unexpected word 'and' in the comments that need to be dropped file: arch/s390/kvm/interrupt.c line: 705 * Subsystem damage are the only two and and are indicated by changed to: * Subsystem damage are the only two and are indicated by Signed-off-by:
Jiang Jian <jiangjian@cdjrlc.com> Link: https://lore.kernel.org/lkml/20220622140720.7617-1-jiangjian@cdjrlc.com/Signed-off-by:
-
Christian Borntraeger authored
KVM: s390/pci: enable zPCI for interpretive execution Add the necessary code in s390 base, pci and KVM to enable interpretion of PCI pasthru.
-
Matthew Rosato authored
Add entries from the s390 kvm subdirectory related to pci passthrough. Acked-by:
Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by:
-
Matthew Rosato authored
The KVM_S390_ZPCI_OP ioctl provides a mechanism for managing hardware-assisted virtualization features for s390x zPCI passthrough. Add the first 2 operations, which can be used to enable/disable the specified device for Adapter Event Notification interpretation. Signed-off-by:
Pierre Morel <pmorel@linux.ibm.com> Reviewed-by:
-
Matthew Rosato authored
When doing load/store interpretation, the maximum store block length is determined by the underlying firmware, not the host kernel API. Reflect that in the associated Query PCI Function Group clp capability and let userspace decide which is appropriate to present to the guest. Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20220606203325.110625-20-mjrosato@linux.ibm.comSigned-off-by:
-
Matthew Rosato authored
The function handle is a system-wide unique identifier for a zPCI device. With zPCI instruction interpretation, the host will no longer be executing the zPCI instructions on behalf of the guest. As a result, the guest needs to use the real function handle in order for firmware to associate the instruction with the proper PCI function. Let's provide that handle to the guest. Reviewed-by:
-
Matthew Rosato authored
During vfio-pci open_device, pass the KVM associated with the vfio group (if one exists). This is needed in order to pass a special indicator (GISA) to firmware to allow zPCI interpretation facilities to be used for only the specific KVM associated with the vfio-pci device. During vfio-pci close_device, unregister the notifier. Signed-off-by:
-
Matthew Rosato authored
These routines will be invoked at the time an s390x vfio-pci device is associated with a KVM (or when the association is removed), allowing the zPCI device to enable or disable load/store intepretation mode; this requires the host zPCI device to inform firmware of the unique token (GISA designation) that is associated with the owning KVM. Signed-off-by:
-
Matthew Rosato authored
These routines will be wired into a kvm ioctl in order to respond to requests to enable / disable a device for Adapter Event Notifications / Adapter Interuption Forwarding. Reviewed-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
-
Matthew Rosato authored
The guest must have access to certain facilities in order to allow interpretive execution of zPCI instructions and adapter event notifications. However, there are some cases where a guest might disable interpretation -- provide a mechanism via which we can defer enabling the associated zPCI interpretation facilities until the guest indicates it wishes to use them. Reviewed-by:
-
Matthew Rosato authored
In cases where interrupts are not forwarded to the guest via firmware, KVM is responsible for ensuring delivery. When an interrupt presents with the forwarding bit, we must process the forwarding tables until all interrupts are delivered. Reviewed-by:
-
Matthew Rosato authored
Initial setup for Adapter Event Notification Interpretation for zPCI passthrough devices. Specifically, allocate a structure for forwarding of adapter events and pass the address of this structure to firmware. Reviewed-by:
-
Matthew Rosato authored
This structure will be used to carry kvm passthrough information related to zPCI devices. Reviewed-by:
-
Matthew Rosato authored
The current contents of vfio-pci-zdev are today only useful in a KVM environment; let's tie everything currently under vfio-pci-zdev to this Kconfig statement and require KVM in this case, reducing complexity (e.g. symbol lookups). Signed-off-by:
-
Matthew Rosato authored
Store information about what IOAT designation types are supported by underlying hardware as well as the largest store block size allowed. These values will be needed by passthrough. Reviewed-by:
-
Matthew Rosato authored
For passthrough devices, we will need to know the GISA designation of the guest if interpretation facilities are to be used. Setup to stash this in the zdev and set a default of 0 (no GISA designation) for now; a subsequent patch will set a valid GISA designation for passthrough devices. Also, extend mpcific routines to specify this stashed designation as part of the mpcific command. Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Matthew Rosato authored
A subsequent patch will be issuing SIC from KVM -- export the necessary routine and make the operation control definitions available from a header. Because the routine will now be exported, let's rename __zpci_set_irq_ctrl to zpci_set_irq_ctrl and get rid of the zero'd iib wrapper function of the same name. Reviewed-by:
-
Matthew Rosato authored
When doing device passthrough where interrupts are being forwarded from host to guest, we wish to use a pinned section of guest memory as the vector (the same memory used by the guest as the vector). To accomplish this, add a new parameter for airq_iv_create which allows passing an existing vector to be used instead of allocating a new one. The caller is responsible for ensuring the vector is pinned in memory as well as for unpinning the memory when the vector is no longer needed. A subsequent patch will use this new parameter for zPCI interpretation. Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
Matthew Rosato authored
A subsequent patch will introduce an airq handler that requires additional TPI information beyond directed vs floating, so pass the entire tpi_info structure via the handler. Only pci actually uses this information today, for the other airq handlers this is effectively a no-op. Reviewed-by:
Eric Farman <farman@linux.ibm.com> Reviewed-by:
-
Matthew Rosato authored
Detect the Adapter Interruption Suppression Interpretation facility. Reviewed-by:
-
Matthew Rosato authored
Detect the Adapter Event Notification Interpretation facility. Reviewed-by:
-
Matthew Rosato authored
Detect the Adapter Interruption Source ID Interpretation facility. Reviewed-by:
-
Matthew Rosato authored
Detect the zPCI Load/Store Interpretation facility. Reviewed-by:
-
- 24 Jun, 2022 9 commits
-
-
Zeng Guang authored
Hardware would directly write x2APIC ICR register instead of software emulation in some circumstances, e.g when Intel IPI virtualization is enabled. This behavior requires normal reserved bits checking to ensure them input as zero, otherwise it will cause #GP. So we need mask out those reserved bits from the data written to vICR register. Remove Delivery Status bit emulation in test case as this flag is invalid and not needed in x2APIC mode. KVM may ignore clearing it during interrupt dispatch which will lead to fake test failure. Opportunistically correct vector number for test sending IPI to non-existent vCPUs. Signed-off-by:
Zeng Guang <guang.zeng@intel.com> Message-Id: <20220623094511.26066-1-guang.zeng@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Jue Wang authored
This patch add a self test that verifies user space can inject UnCorrectable No Action required (UCNA) memory errors to the guest. It also verifies that incorrectly configured MSRs for Corrected Machine Check Interrupt (CMCI) emulation will result in #GP. Signed-off-by:
Jue Wang <juew@google.com> Signed-off-by:
-
Jue Wang authored
This patch enables MCG_CMCI_P by default in kvm_mce_cap_supported. It reuses ioctl KVM_X86_SET_MCE to implement injection of UnCorrectable No Action required (UCNA) errors, signaled via Corrected Machine Check Interrupt (CMCI). Neither of the CMCI and UCNA emulations depends on hardware. Signed-off-by:
-
Jue Wang authored
This patch adds the emulation of IA32_MCi_CTL2 registers to KVM. A separate mci_ctl2_banks array is used to keep the existing mce_banks register layout intact. In Machine Check Architecture, in addition to MCG_CMCI_P, bit 30 of the per-bank register IA32_MCi_CTL2 controls whether Corrected Machine Check error reporting is enabled. Signed-off-by:
-
Jue Wang authored
This patch updates the allocation of mce_banks with the array allocation API (kcalloc) as a precedent for the later mci_ctl2_banks to implement per-bank control of Corrected Machine Check Interrupt (CMCI). Suggested-by:
Sean Christopherson <seanjc@google.com> Signed-off-by:
-
Jue Wang authored
This patch calculates the number of lvt entries as part of KVM_X86_MCE_SETUP conditioned on the presence of MCG_CMCI_P bit in MCG_CAP and stores result in kvm_lapic. It translats from APIC_LVTx register to index in lapic_lvt_entry enum. It extends the APIC_LVTx macro as well as other lapic write/reset handling etc to support Corrected Machine Check Interrupt. Signed-off-by:
-
Jue Wang authored
An APIC_LVTx macro is introduced to calcualte the APIC_LVTx register offset based on the index in the lapic_lvt_entry enum. Later patches will extend the APIC_LVTx macro to support the APIC_LVTCMCI register in order to implement Corrected Machine Check Interrupt signaling. Suggested-by:
-
Jue Wang authored
This patch defines a lapic_lvt_entry enum used as explicit indices to the apic_lvt_mask array. In later patches a LVT_CMCI will be added to implement the Corrected Machine Check Interrupt signaling. Suggested-by:
-
Jue Wang authored
Refactor APIC_VERSION so that the maximum number of LVT entries is inserted at runtime rather than compile time. This will be used in a subsequent commit to expose the LVT CMCI Register to VMs that support Corrected Machine Check error counting/signaling (IA32_MCG_CAP.MCG_CMCI_P=1). Suggested-by:
-
