aboutsummaryrefslogtreecommitdiff
path: root/target/s390x
AgeCommit message (Collapse)Author
2019-03-11s390x/tcg: Implement VECTOR LOAD AND REPLICATEDavid Hildenbrand
We can use tcg_gen_gvec_dup_i64() to carry out the duplication. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-9-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Implement VECTOR LOADDavid Hildenbrand
When loading from memory, load both elements into temps first before modifying the target vector Loading with strange alingment from the end of the address space will not properly wrap, we can ignore that for now. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-8-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Implement VECTOR GENERATE MASKDavid Hildenbrand
Add gen_gvec_dupi() for handling duplication of immediates, so it can be reused later. Reviewed-by: Richard Henderson <richard.henderson@linaro.org Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-7-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Implement VECTOR GENERATE BYTE MASKDavid Hildenbrand
Let's optimize it for the common cases (setting a vector to zero or all ones) - courtesy of Richard. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Implement VECTOR GATHER ELEMENTDavid Hildenbrand
Let's start with a more involved one, but it is the first in the list of vector support instructions (introduced with the vector facility). Good thing is, we need a lot of basic infrastructure for this. Reading and writing vector elements as well as checking element validity. All vector instruction related translation functions will reside in translate_vx.inc.c, to be included in translate.c - similar to how other architectures handle it. While at it, directly add some documentation (which contains parts about things added in follow-up patches, but splitting this up does not make too much sense). Also add ES_* defines heavily used later. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-5-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Utilities for vector instruction helpersDavid Hildenbrand
We'll have to read/write vector elements quite frequently from helpers. The tricky bit is properly taking care of endianess. Handle it similar to aarch64. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-4-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Check vector register instructions at central pointDavid Hildenbrand
Check them at a central point. We'll use a new instruction flag to flag all vector instructions (IF_VEC) and handle it very similar to AFP, whereby we use another unused position in the PSW mask to store the state of vector register enablement per translation block. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-3-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11s390x/tcg: Define vector instruction formatsDavid Hildenbrand
These are the new instruction formats related to vector instructions as up to the z14 (a.k.a. latest PoP). As v2 appeares (like x2 in VRX) with d2/b2 in VRV, we have to assign it a higher field number to avoid collisions. Properly take care of the MSB (to be able to address 32 registers) for each vector register field stored in the RXB field (Bit 36 - 30 for all vector instructions). As we have 32 bit vector registers and the "v" fields are only 4 bit in size, the 5th bit is stored in the RXB. We use a new type to indicate that the MSB has to be fetched from the RXB. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190307121539.12842-2-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-11target/s390x: Remove non-architected entries from struct LowCoreThomas Huth
There are some fields in our struct LowCore which apparently have been copied from a very old version of the Linux kernel. These fields are not architected in the "Principles of Operation", and only used on these memory locations in Linux kernels older than 2.6.29. Newer Linux kernels moved the entries to different locations or are not using them at all anymore. Thus we should never access these fields from the QEMU side, so they should be removed. While we're at it, also add a QEMU_BUILD_BUG_ON() statement to assert that struct LowCore has the right size. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1551775581-27989-1-git-send-email-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x: Add floating-point extension facility to "qemu" cpu modelDavid Hildenbrand
The floating-point extension facility implemented certain changes to BFP, HFP and DFP instructions. As we don't implement HFP/DFP, we can ignore those completely. Related to BFP, the changes include - SET BFP ROUNDING MODE (SRNMB) instruction - BFP-rounding-mode field in the FPC register is changed to 3 bits - CONVERT FROM LOGICAL instructions - CONVERT TO LOGICAL instructions - Changes (rounding mode + XxC) added to -- CONVERT TO FIXED -- CONVERT FROM FIXED -- LOAD FP INTEGER -- LOAD ROUNDED -- DIVIDE TO INTEGER For TCG, we don't implement DIVIDE TO INTEGER, and it is harder to implement, so skip that. Also, as we don't implement PFPO, we can skip changes to that as well. The other parts are now implemented, we can indicate the facility. z14 PoP mentions that "The floating-point extension facility is installed in the z/Architecture architectural mode. When bit 37 is one, bit 42 is also one.", meaning that the DFP (decimal-floating-point) facility also has to be indicated. We can ignore that for now. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-16-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Handle all rounding modes overwritten by BFP instructionsDavid Hildenbrand
"round to nearest with ties away from 0" maps to float_round_ties_away. "round to prepare for shorter precision" maps to float_round_to_odd. As all instructions properly check for valid rounding modes in translate.c we can add an assert. Fix one missing empty line. Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-15-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Implement rounding mode and XxC for LOAD ROUNDEDDavid Hildenbrand
With the floating-point extension facility, LOAD ROUNDED has a rounding mode specification and the inexact-exception control (XxC). Handle them just like e.g. LOAD FP INTEGER. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-14-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Implement XxC and checks for most FP instructionsDavid Hildenbrand
With the floating-point extension facility - CONVERT FROM LOGICAL - CONVERT TO LOGICAL - CONVERT TO FIXED - CONVERT FROM FIXED - LOAD FP INTEGER have both, a rounding mode specification and the inexact-exception control (XxC). Other instructions will be handled separatly. Check for valid rounding modes and forward also the XxC (via m4). To avoid a lot of boilerplate code and changes to the helpers, combine both, the m3 and m4 field in a combined 32 bit TCG variable. Perform checks at a central place, taking in account if the m3 or m4 field was ignore before the floating-point extension facility was introduced. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-13-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Prepare for IEEE-inexact-exception control (XxC)David Hildenbrand
Some instructions allow to suppress IEEE inexact exceptions. z14 PoP, 9-23, "Suppression of Certain IEEE Exceptions" IEEE-inexact-exception control (XxC): Bit 1 of the M4 field is the XxC bit. If XxC is zero, recogni- tion of IEEE-inexact exception is not suppressed; if XxC is one, recognition of IEEE-inexact excep- tion is suppressed. Especially, handling for overflow/unerflow remains as is, inexact is reported along z14 PoP, 9-23, "Suppression of Certain IEEE Exceptions" For example, the IEEE-inexact-exception control (XxC) has no effect on the DXC; that is, the DXC for IEEE- overflow or IEEE-underflow exceptions along with the detail for exact, inexact and truncated, or inexact and incremented, is reported according to the actual con- dition. Follow up patches will wire it correctly up for the applicable instructions. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-12-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Refactor saving/restoring the bfp rounding modeDavid Hildenbrand
We want to reuse this in the context of vector instructions. So use better matching names and introduce s390_restore_bfp_rounding_mode(). While at it, add proper newlines. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-11-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Check for exceptions in SET BFP ROUNDING MODEDavid Hildenbrand
Let's split handling of BFP/DFP rounding mode configuration. Also, let's not reuse the sfpc handler, use a separate handler so we can properly check for specification exceptions for SRNMB. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-10-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Handle SET FPC AND LOAD FPC 3-bit BFP rounding modesDavid Hildenbrand
We already forward the 3 bits correctly in the translation functions. We also have to handle them properly and check for specification exceptions. Setting an invalid rounding mode (BFP only, all DFP rounding modes) results in a specification exception. Setting unassigned bits in the fpc, results in a specification exception. This fixes LOAD FPC (AND SIGNAL), SET FPC (AND SIGNAL). Also for, SET BFP ROUNDING MODE, 3-bit rounding mode is now explicitly checked. Note: TCG_CALL_NO_WG is required for sfpc handler, as we now inject exceptions. We won't be modeling abscence of the "floating-point extension facility" for now, not necessary as most take the facility for granted without checking. z14 PoP, 9-23, "LOAD FPC" When the floating-point extension facility is installed, bits 29-31 of the second operand must specify a valid BFP rounding mode and bits 6-7, 14-15, 24, and 28 must be zero; otherwise, a specification exception is recognized. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-9-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Fix simulated-IEEE exceptionsDavid Hildenbrand
The trap is triggered based on priority of the enabled signaling flags. Only overflow and underflow allow a concurrent inexact exception. z14 PoP, 9-33, Figure 9-21 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-8-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Refactor SET FPC AND SIGNAL handlingDavid Hildenbrand
We can directly work on the uint64_t value, no need for a temporary uint32_t value. Also cleanup and shorten the comments. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-7-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Hide IEEE underflows in some scenariosDavid Hildenbrand
IEEE underflows are not reported when the mask bit is off and we don't also have an inexact exception. z14 PoP, 9-20, "IEEE Underflow": An IEEE-underflow exception is recognized for an IEEE target when the tininess condition exists and either: (1) the IEEE-underflow mask bit in the FPC register is zero and the result value is inexact, or (2) the IEEE-underflow mask bit in the FPC register is one. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Fix parts of IEEE exception handlingDavid Hildenbrand
Many things are wrong and some parts cannot be fixed yet. Fix what we can fix easily and add two FIXMEs: The fpc flags are not updated in case an exception is actually injected. Inexact exceptions have to be handled separately, as they are the only exceptions that can coexist with underflows and overflows. I reread the horribly complicated chapters in the PoP at least 5 times and hope I got it right. For references: - z14 PoP, 9-18, "IEEE Exceptions" - z14 PoP, 19-9, Figure 19-8 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-5-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Factor out conversion of softfloat exceptionsDavid Hildenbrand
We want to reuse that function in vector instruction context. While at it, cleanup the code, using defines for magic values and avoiding the handcrafted bit conversion. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-4-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Fix rounding from float128 to uint64_t/uint32_tDavid Hildenbrand
Let's use the proper conversion functions now that we have them. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-3-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Fix TEST DATA CLASS instructionsDavid Hildenbrand
Let's detect normal and denormal ("subnormal") numbers reliably. Also test for quiet NaN's. As only one class is possible, test common cases first. While at it, use a better check to test for the mask bits in the data class mask. The data class mask has 12 bits, whereby bit 0 is the leftmost bit and bit 11 the rightmost bit. In the PoP an easy to read table with the numbers is provided for the VECTOR FP TEST DATA CLASS IMMEDIATE instruction, the table for TEST DATA CLASS is more confusing as it is based on 64 bit values. Factor the checks out into separate functions, as they will also be needed for floating point vector instructions. We can use a makro to generate the functions. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218122710.23639-2-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Implement LOAD COUNT TO BLOCK BOUNDARYDavid Hildenbrand
Use a new CC helper to calculate the CC lazily if needed. While the PoP mentions that "A 32-bit unsigned binary integer" is placed into the first operand, there is no word telling that the other 32 bits (high part) are left untouched. Maybe the other 32-bit are unpredictable. So store 64 bit for now. Bit magic courtesy of Richard. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-8-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Implement LOAD LENGTHENED short HFP to long HFPDavid Hildenbrand
Nice trick to load a 32 bit value into vector element 0 (32 bit element size) from memory, zeroing out element1. The short HFP to long HFP conversion really only is a shift. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-7-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Factor out gen_addi_and_wrap_i64() from get_address()David Hildenbrand
Also properly wrap in 24bit mode. While at it, convert the comment (and drop the comment about fundamental TCG optimizations). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Factor out vec_full_reg_offset()David Hildenbrand
We'll use that a lot along with gvec helpers, to calculate the start address of a vector. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-5-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Clarify terminology in vec_reg_offset()David Hildenbrand
We will use s390x speak "Element Size" (es) for MO_8 == 0, MO_16 == 1 ... Simple rename of variables. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-4-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Simplify disassembler operands initializationDavid Hildenbrand
Let's simplify initialization to 0. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-3-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: RXE has an optional M3 fieldDavid Hildenbrand
Will be needed, so add it to the format description. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190225200318.16102-2-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x/tcg: Save vregs to extended mchk save areaDavid Hildenbrand
If we have vector registers and the designation is not zero, we have to try to write the vector registers. If the designation is zero or if storing fails, we must not indicate validity. s390_build_validity_mcic() automatically already sets validity if the vector instruction facility is installed. As long as we don't support the guarded-storage facility, the alignment and size of the area is always 1024 bytes. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190222081153.14206-4-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x: use a QEMU-style typedef + name for SIGP save area structDavid Hildenbrand
Convert this to QEMU style. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190222081153.14206-3-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-03-04s390x: Use cpu_to_be64 in SIGP STORE ADDITIONAL STATUSDavid Hildenbrand
As we will support vector instructions soon, and vector registers are stored in 64bit host chunks, let's use cpu_to_be64. Same applies to the guarded storage control block. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190222081153.14206-2-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-02-18' into ↵Peter Maydell
staging QAPI patches for 2019-02-18 # gpg: Signature made Mon 18 Feb 2019 13:44:30 GMT # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-qapi-2019-02-18: qapi: move RTC_CHANGE to the target schema qmp: Deprecate query-events in favor of query-qmp-schema Revert "qapi-events: add 'if' condition to implicit event enum" qapi: remove qmp_unregister_command() qapi: make query-cpu-definitions depend on specific targets qapi: make query-cpu-model-expansion depend on s390 or x86 qapi: make query-gic-capabilities depend on TARGET_ARM target.json: add a note about query-cpu* not being s390x-specific qapi: make s390 commands depend on TARGET_S390X qapi: make rtc-reset-reinjection and SEV depend on TARGET_I386 qapi: New module target.json build: Deal with all of QAPI's .o in qapi/Makefile.objs build-sys: move qmp-introspect per target qapi: Generate QAPIEvent stuff into separate files qapi: Prepare for system modules other than 'builtin' qapi: Clean up modular built-in code generation a bit qapi: Fix up documentation for recent commit a95291007b2 qapi: Belatedly document modular code generation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-18qapi: make query-cpu-definitions depend on specific targetsMarc-André Lureau
It depends on TARGET_PPC || TARGET_ARM || TARGET_I386 || TARGET_S390X. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-15-armbru@redhat.com>
2019-02-18qapi: make query-cpu-model-expansion depend on s390 or x86Marc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-14-armbru@redhat.com>
2019-02-18qapi: make s390 commands depend on TARGET_S390XMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-11-armbru@redhat.com>
2019-02-18s390x/kvm: add tracepoint to ioeventfd interfaceCornelia Huck
Trace when assigning/unassigning. Message-Id: <20190212153025.25425-1-cohuck@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x/cpumodel: add z14 GA2 modelCollin Walling
Introduce the z14 GA2 cpu model for QEMU. There are no new features introduced with this model, and will inherit the same feature set as z14 GA1. Signed-off-by: Collin Walling <walling@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20190212011657.18324-3-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x/cpumodel: default enable mepoch for z14 and laterCollin Walling
Latest systems and host kernels support mepoch, which is a feature that was meant to be supported for z14 GA1 from the get-go. Let's copy it to the z14 GA1 default CPU model. Machines s390-ccw-virtio-3.1 and older will retain the old CPU models and will not provide this bit nor the extended PTFF functions in the default model. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <20190212011657.18324-2-walling@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x/cpumodel: mepochptff: warn when no mepoch and re-align group initCollin Walling
The extended PTFF features (qsie, qtoue, stoe, stoue) are dependent on the multiple-epoch facility (mepoch). Let's print a warning if these features are enabled without mepoch. While we're at it, let's move the FEAT_GROUP_INIT for mepochptff down the s390_feature_groups list so it can be properly indexed with its generated S390FeatGroup enum. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <20190212011657.18324-1-walling@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x: add zPCI feature to "qemu" CPU modelDavid Hildenbrand
As we now always have PCI support, let's add it to the "qemu" CPU model, taking care of backwards compatibility. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190212112323.15904-1-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18target/s390x: Implement STCK et al for CONFIG_USER_ONLYRichard Henderson
This is a non-privileged instruction that was only implemented for system mode. However, the stck instruction is used by glibc, so this was causing SIGILL for programs run under debian stretch. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190212053044.29015-3-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18target/s390x: Split out s390-tod.hRichard Henderson
We will need these from CONFIG_USER_ONLY as well, which cannot access include/hw/. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190212053044.29015-2-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x: always provide pci supportCornelia Huck
We tried to make pci support optional on s390x in the past; unfortunately, we still require the s390 phb to be created unconditionally due to backwards compatibility issues. Instead of sinking more effort into this (including compat handling for older machines etc.) for non-obvious gains, let's just make CONFIG_PCI something that is always set on s390x. Note that you can still fence off pci for the _guest_ if you provide a cpu model without the zpci feature. Message-Id: <20190211113255.3837-1-cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x: Fix the confusing contributions-after-2012 license statementsThomas Huth
The license information in these files is rather confusing. The text declares LGPL first, but then says that contributions after 2012 are licensed under the GPL instead. How should the average user who just downloaded the release tarball know which part is now GPL and which is LGPL? Looking at the text of the LGPL (see COPYING.LIB in the top directory), the license clearly states how this should be done instead: "3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License." Thus let's clean up the confusing statements and use the proper GPL text only. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1549456893-16589-1-git-send-email-thuth@redhat.com> Acked-by: Laurent Vivier <laurent@vivier.eu> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04s390x/tcg: Don't model FP registers as globalsDavid Hildenbrand
As floating point registers overlay some vector registers and we want to make use of the general tcg_gvec infrastructure that assumes vectors are not stored in globals but in memory, don't model floating point registers as globals anymore. This is then similar to how arm handles it. Reading/writing a floating point register means reading/writing memory now. Break up ugly in2_x2() handling that modifies both, in1 and in2 into in2_x2l and in2_x2h. This makes things more readable. Also, in1_x1() is ugly as it touches out/out2, get rid of that and use prep_x1() instead. As we are no longer able to use the original global variables for out/out2, we have to use new temporary variables and write from them to the target registers using wout_ helpers. E.g. an instruction that reads and writes x1 will use - prep_x1 to get the values into out/out2 - wout_x1 to write the values from out/out2 This special handling is needed for x1 as it is often used along with other inputs, so in1/in2 is already used. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190204154406.16122-1-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04s390x: remove direct reference to mem_path global from s390x codeIgor Mammedov
I plan to deprecate -mem-path option and replace it with memory-backend, for that it's necessary to get rid of mem_path global variable. Do it for s390x case, replacing it with alternative way to enable 1Mb hugepages capability. Todo that replace qemu_mempath_getpagesize() with qemu_getrampagesize() which also checks for -mem-path provided RAM. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <1548834906-133241-1-git-send-email-imammedo@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04target/s390x: define TCG_GUEST_DEFAULT_MO for MTTCGAlex Bennée
MTTCG should be enabled by default whenever the memory model allows it. s390x was missing its definition of TCG_GUEST_DEFAULT_MO meaning the user had to manually specify --accel tcg,thread=multi. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: David Hildenbrand <david@redhat.com> Message-Id: <20190118171848.27332-1-alex.bennee@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>