- 10 Jun, 2016 40 commits
-
-
David Hildenbrand authored
We can safe a few LOC and make that function easier to understand by rewriting existing code. Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
Move the mmap semaphore locking out of set_guest_storage_key and get_guest_storage_key. This makes the two functions more like the other ptep_xxx operations and allows to avoid repeated semaphore operations if multiple keys are read or written. Reviewed-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
David Hildenbrand authored
Commit 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c") changed the return value of get_guest_storage_key to an unsigned char, resulting in -EFAULT getting interpreted as a valid storage key. Cc: stable@vger.kernel.org # 4.6+ Reviewed-by:
-
Christian Borntraeger authored
We currently have two issues with the I/O interrupt injection logging: 1. All QEMU versions up to 2.6 have a wrong encoding of device numbers etc for the I/O interrupt type, so the inject VM_EVENT will have wrong data. Let's fix this by using the interrupt parameters and not the interrupt type number. 2. We only log in kvm_s390_inject_vm, but not when coming from kvm_s390_reinject_io_int or from flic. Let's move the logging to the common __inject_io function. We also enhance the logging for delivery to match the data. Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com>
-
Christian Borntraeger authored
We might need to debug some virtio things, so better have diagnose 500 logged. Signed-off-by:
-
David Hildenbrand authored
Constrained transactional execution is an addon of transactional execution. Let's enable the assist also if only TX is enabled for the guest. Reviewed-by:
-
David Hildenbrand authored
host-protection-interruption control was introduced with ESOP. So let's enable it only if we have ESOP and add an explanatory comment why we can live without it. Reviewed-by:
-
David Hildenbrand authored
Let's enable interlock-and-broadcast suppression only if the facility is actually available. Reviewed-by:
-
David Hildenbrand authored
Let's detect that facility. Reviewed-by:
-
David Hildenbrand authored
Let's enable interpretation of PFMFI only if the facility is actually available. Emulation code still works in case the guest is offered EDAT-1. Reviewed-by:
-
David Hildenbrand authored
Let's detect that facility. Reviewed-by:
-
David Hildenbrand authored
Let's only enable conditional-external-interruption if the facility is actually available. Reviewed-by:
-
David Hildenbrand authored
Let's detect if we have that facility. Reviewed-by:
-
David Hildenbrand authored
Let's enable intervention bypass only if the facility is acutally available. Reviewed-by:
-
David Hildenbrand authored
Let's detect if we have the intervention bypass facility installed. Reviewed-by:
-
David Hildenbrand authored
If guest-storage-limit-suppression is not available, we would for now have a valid guest address space with size 0. So let's simply set the origin to 0 and the limit to hamax. Signed-off-by:
-
David Hildenbrand authored
Let's detect that facility. Reviewed-by:
-
David Hildenbrand authored
Let's not provide the device attribute for cmma enabling and clearing if the hardware doesn't support it. This also helps getting rid of the undocumented return value "-EINVAL" in case CMMA is not available when trying to enable it. Also properly document the meaning of -EINVAL for CMMA clearing. Reviewed-by:
-
David Hildenbrand authored
Now that we can detect if collaborative-memory-management interpretation is available, replace the heuristic by a real hardware detection. Signed-off-by:
-
David Hildenbrand authored
Let's detect the Collaborative-memory-management-interpretation facility, aka CMM assist, so we can correctly enable cmma later. Signed-off-by:
-
David Hildenbrand authored
Without guest-PER enhancement, we can't provide any debugging support. Therefore act like kernel support is missing. Reviewed-by:
-
David Hildenbrand authored
Let's detect that facility, so we can correctly handle its abscence. Reviewed-by:
-
David Hildenbrand authored
Without that facility, we may only use scaol. So fallback to DMA allocation in that case, so we won't overwrite random memory via the SIE. Also disallow ESCA, so we don't have to handle that allocation case. Reviewed-by:
-
David Hildenbrand authored
Let's correctly detect that facility, so we can correctly handle its abscence later on. Reviewed-by:
-
David Hildenbrand authored
We have certain instructions that indicate available subfunctions via a query subfunction (crypto functions and ptff), or via a test bit function (plo). By exposing these "subfunction blocks" to user space, we allow user space to 1) query available subfunctions and make sure subfunctions won't get lost during migration - e.g. properly indicate them via a CPU model 2) change the subfunctions to be reported to the guest (even adding unavailable ones) This mechanism works just like the way we indicate the stfl(e) list to user space. This way, user space could even emulate some subfunctions in QEMU in the future. If this is ever applicable, we have to make sure later on, that unsupported subfunctions result in an intercept to QEMU. Please note that support to indicate them to the guest is still missing and requires hardware support. Usually, the IBC takes already care of these subfunctions for migration safety. QEMU should make sure to always set these bits properly according to the machine generation to be emulated. Available subfunctions are only valid in combination with STFLE bits retrieved via KVM_S390_VM_CPU_MACHINE and enabled via KVM_S390_VM_CPU_PROCESSOR. If the applicable bits are available, the indicated subfunctions are guaranteed to be correct. Signed-off-by:
-
David Hildenbrand authored
KVM will have to query these functions, let's add at least the query capabilities. PCKMO has RRE format, as bit 16-31 are ignored, we can still use the existing function. As PCKMO won't touch the cc, let's force it to 0 upfront. Signed-off-by:
Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by:
-
David Hildenbrand authored
Let's use our new function for preparing translation exceptions. Signed-off-by:
-
David Hildenbrand authored
Let's use our new function for preparing translation exceptions. As we will need the correct ar, let's pass that to guest_page_range(). This will also make sure that the guest address is stored in the tec for applicable excptions. Signed-off-by:
-
David Hildenbrand authored
Let's use our new function for preparing translation exceptions. Signed-off-by:
-
David Hildenbrand authored
Let's use our new function for preparing translation exceptions. Signed-off-by:
-
David Hildenbrand authored
Let's provide a function trans_exc() that can be used for handling preparation of translation exceptions on a central basis. We will use that function to replace existing code in gaccess. Signed-off-by:
-
David Hildenbrand authored
Let's pass the effective guest address to get_vcpu_asce(), so we can properly set the guest address in case we inject an ALC protection exception. Signed-off-by:
-
David Hildenbrand authored
ESOP guarantees that during a protection exception, bit 61 of real location 168-175 will only be set to 1 if it was because of ALCP or DATP. If the exception is due to LAP or KCP, the bit will always be set to 0. The old SOP definition allowed bit 61 to be unpredictable in case of LAP or KCP in some conditions. So ESOP replaces this unpredictability by a guarantee. Therefore, we can directly forward ESOP if it is available on our machine. We don't have to do anything when ESOP is disabled - the guest will simply expect unpredictable values. Our guest access functions are already handling ESOP properly. Please note that future functionality in KVM will require knowledge about ESOP being enabled for a guest or not. Reviewed-by:
-
David Hildenbrand authored
For now, we only have an interface to query and configure facilities indicated via STFL(E). However, we also have features indicated via SCLP, that have to be indicated to the guest by user space and usually require KVM support. This patch allows user space to query and configure available cpu features for the guest. Please note that disabling a feature doesn't necessarily mean that it is completely disabled (e.g. ESOP is mostly handled by the SIE). We will try our best to disable it. Most features (e.g. SCLP) can't directly be forwarded, as most of them need in addition to hardware support, support in KVM. As we later on want to turn these features in KVM explicitly on/off (to simulate different behavior), we have to filter all features provided by the hardware and make them configurable. Signed-off-by:
-
Alexander Yarygin authored
We have a table of mnemonic names for intercepted program interruptions, let's print readable name of the interruption in the kvm_s390_intercept_prog trace event. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Acked-by:
-
Janosch Frank authored
Store hypervisor information is a valid instruction not only in supervisor state but also in problem state, i.e. the guest's userspace. Its execution is not only computational and memory intensive, but also has to get hold of the ipte lock to write to the guest's memory. This lock is not intended to be held often and long, especially not from the untrusted guest userspace. Therefore we apply rate limiting of sthyi executions per VM. Signed-off-by:
Janosch Frank <frankja@linux.vnet.ibm.com> Acked-by:
-
Janosch Frank authored
Store Hypervisor Information is an emulated z/VM instruction that provides a guest with basic information about the layers it is running on. This includes information about the cpu configuration of both the machine and the lpar, as well as their names, machine model and machine type. This information enables an application to determine the maximum capacity of CPs and IFLs available to software. The instruction is available whenever the facility bit 74 is set, otherwise executing it results in an operation exception. It is important to check the validity flags in the sections before using data from any structure member. It is not guaranteed that all members will be valid on all machines / machine configurations. Signed-off-by:
-
Janosch Frank authored
The new store hypervisor information instruction, which we are going to introduce, needs previously unused fields in diag 204 structures. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Janosch Frank authored
This commit introduces code that handles operation exception interceptions. With this handler we can emulate instructions by using illegal opcodes. Signed-off-by:
-
Janosch Frank authored
Diag204's cpu structures only contain the cpu type by means of an index in the diag224 name table. Hence, to be able to use diag204 in any meaningful way, we also need a usable diag224 interface. Signed-off-by:
-
