Commit Graph

42 Commits

Author SHA1 Message Date
David Hildenbrand
be2b567018 s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)
As with the other crypto functions, we only implement subcode 0 (query)
and no actual encryption/decryption. We now implement S390_FEAT_MSA_EXT_8.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-10-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02 13:52:49 +02:00
David Hildenbrand
e0f28bb210 s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2
We implement all relevant instructions.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-9-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02 13:52:49 +02:00
David Hildenbrand
98998cda5d s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> S390_FEAT_MISC_INSTRUCTION_EXT2
Let's avoid confusion with the "Miscellaneous-Instruction-Extensions
Facility 1"

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20200928122717.30586-2-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02 13:52:49 +02:00
Collin Walling
fabdada935 s390: guest support for diagnose 0x318
DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
of diagnostic information that is collected by the firmware in the case
of hardware/firmware service events.

QEMU handles the instruction by storing the info in the CPU state. A
subsequent register sync will communicate the data to the hypervisor.

QEMU handles the migration via a VM State Description.

This feature depends on the Extended-Length SCCB (els) feature. If
els is not present, then a warning will be printed and the SCLP bit
that allows the Linux kernel to execute the instruction will not be
set.

Availability of this instruction is determined by byte 134 (aka fac134)
bit 0 of the SCLP Read Info block. This coincidentally expands into the
space used for CPU entries, which means VMs running with the diag318
capability may not be able to read information regarding all CPUs
unless the guest kernel supports an extended-length SCCB.

This feature is not supported in protected virtualization mode.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-9-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02 13:52:49 +02:00
Collin Walling
1ecd6078f5 s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.

With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.

The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.

This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.

When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.

In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.

Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02 13:52:49 +02:00
Christian Borntraeger
572c082661 s390x: Add unpack facility feature to GA1
The unpack facility is an indication that diagnose 308 subcodes 8-10
are available to the guest. That means, that the guest can put itself
into protected mode.

Once it is in protected mode, the hardware stops any attempt of VM
introspection by the hypervisor.

Some features are currently not supported in protected mode:
     * vfio devices
     * Migration
     * Huge page backings

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20200319131921.2367-17-frankja@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-04-29 14:31:32 +02:00
David Hildenbrand
b580b6ee05 s390x/cpumodel: Add new TCG features to QEMU cpu model
We now implement a bunch of new facilities we can properly indicate.

ESOP-1/ESOP-2 handling is discussed in the PoP Chafter 3-15
("Suppression on Protection"). The "Basic suppression-on-protection (SOP)
facility" is a core part of z/Architecture without a facility
indication. ESOP-2 is indicated by ESOP-1 + Side-effect facility
("ESOP-2"). Besides ESOP-2, the side-effect facility is only relevant for
the guarded-storage facility (we don't implement).

S390_ESOP:
- We indicate DAT exeptions by setting bit 61 of the TEID (TEC) to 1 and
  bit 60 to zero. We don't trigger ALCP exceptions yet. Also, we set
  bit 0-51 and bit 62/63 to the right values.
S390_ACCESS_EXCEPTION_FS_INDICATION:
- The TEID (TEC) properly indicates in bit 52/53 on any access if it was
  a fetch or a store
S390_SIDE_EFFECT_ACCESS_ESOP2:
- We have no side-effect accesses (esp., we don't implement the
  guarded-storage faciliy), we correctly set bit 64 of the TEID (TEC) to
  0 (no side-effect).
- ESOP2: We properly set bit 56, 60, 61 in the TEID (TEC) to indicate the
  type of protection. We don't trigger KCP/ALCP exceptions yet.
S390_INSTRUCTION_EXEC_PROT:
- The MMU properly detects and indicates the exception on instruction fetches
- Protected TLB entries will never get PAGE_EXEC set.

There is no need to fake the abscence of any of the facilities - without
the facilities, some bits of the TEID (TEC) are simply unpredictable.

As IEP was added with z14 and we currently implement a z13, add it to
the MAX model instead.

Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2019-10-09 12:49:01 +02:00
David Hildenbrand
faa40177bb s390x/cpumodel: Prepare for changes of QEMU model
Setup the 4.1 compatibility model so we can add new features to the
LATEST model.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2019-10-09 12:49:01 +02:00
Christian Borntraeger
5d8866c898 s390x/cpumodel: change internal name of vxpdeh to match description
The internal macro name VECTOR_BCD_ENH does not match the actual
description. Fix this.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20190715142304.215018-4-borntraeger@de.ibm.com>
[CH: vxp->vxpdeh, as discussed]
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-07-16 11:29:38 +02:00
Christian Borntraeger
de6bb08570 s390x/cpumodel: remove esort from the default model
esort might not be available on all models.

Fixes: caef62430f ("s390x/cpumodel: add gen15 defintions")
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20190715142304.215018-2-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-07-16 11:29:05 +02:00
Pierre Morel
9ef2d19e5f s390x/cpumodel: Set up CPU model for AQIC interception
Let's add support for the AP-Queue interruption facility to the CPU
model.

The S390_FEAT_AP_QUEUE_INTERRUPT_CONTROL, CPU facility indicates
whether the PQAP instruction with the AQIC command is available
to the guest.
This feature will be enabled only if the AP instructions are
available on the linux host and AQIC facility is installed on
the host.

This feature must be turned on from userspace to intercept AP
instructions on the KVM guest. The QEMU command line to turn
this feature on looks something like this:

    qemu-system-s390x ... -cpu xxx,apqi=on ...
or
    ... -cpu host

Right now AP pass-through devices do not support migration,
which means that we do not have to take care of migrating
the interrupt data:
virsh migrate apguest --live qemu+ssh://root@target.lan/system
error: Requested operation is not valid: domain has assigned non-USB host devices

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
[rebase to newest qemu and fixup description]
Message-Id: <20190705153249.12525-1-borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-07-08 12:57:16 +02:00
David Hildenbrand
ef506f804a s390x/cpumodel: Prepend KDSA features with "KDSA"
Let's handle it just like for other crypto features.

Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2019-06-21 15:26:53 +02:00
David Hildenbrand
08ef92d556 s390x: Bump the "qemu" CPU model up to a stripped-down z13
We don't care about the other two missing base features:
- S390_FEAT_DFP_PACKED_CONVERSION
- S390_FEAT_GROUP_GEN13_PTFF

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
2019-06-07 14:53:26 +02:00
David Hildenbrand
c7f22b31ce s390x/tcg: We support the Vector Facility
Let's add it to the max model, so we can enable it.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
2019-06-07 14:53:26 +02:00
Christian Borntraeger
caef62430f s390x/cpumodel: add gen15 defintions
add several new features (msa9, sort, deflate, additional vector
instructions, new general purpose instructions) to generation 15.

Also disable csske and bpb from the default and base models >=15.
This will allow to migrate gen15 machines to future machines that
do not have these features.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20190429090250.7648-9-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-05-21 16:59:16 +02:00
Christian Borntraeger
afc7b8666b s390x/cpumodel: add Deflate-conversion facility
add the deflate conversion facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20190429090250.7648-8-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-05-21 16:59:16 +02:00
Christian Borntraeger
d220fabf16 s390x/cpumodel: enhanced sort facility
add the enhanced sort facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190429090250.7648-7-borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-05-21 16:59:16 +02:00
Christian Borntraeger
5dacbe23d2 s390x/cpumodel: msa9 facility
Provide the MSA9 facility (stfle.155). This also contains pckmo
subfunctions for key wrapping. Keep them in a separate group to disable
those as a block if necessary. This is for example needed when disabling
key wrapping via the HMC.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20190429090250.7648-5-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-05-21 16:59:16 +02:00
David Hildenbrand
df192fbc51 s390x: Add floating-point extension facility to "qemu" cpu model
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-04 11:49:31 +01:00
Collin Walling
f2a7d15771 s390x/cpumodel: add z14 GA2 model
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-18 11:25:43 +01:00
Collin Walling
84176c7906 s390x/cpumodel: default enable mepoch for z14 and later
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-18 11:25:43 +01:00
David Hildenbrand
d646b16b21 s390x: add zPCI feature to "qemu" CPU model
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-18 11:25:43 +01:00
Cornelia Huck
09ced81aac s390x: always provide pci support
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-18 11:25:43 +01:00
Tony Krowiak
c5cd17afdd s390x/cpumodel: Set up CPU model for AP device support
A new CPU model feature and two new CPU model facilities are
introduced to support AP devices for a KVM guest.

CPU model features:

1. The S390_FEAT_AP CPU model feature indicates whether AP
   instructions are available to the guest. This feature will
   be enabled only if the AP instructions are available on the
   linux host as determined by the availability of the
   KVM_S390_VM_CRYPTO_ENABLE_APIE VM attribute which is exposed
   by KVM only if the AP instructions are available on the
   host.

   This feature must be turned on from userspace to execute AP
   instructions on the KVM guest. The QEMU command line to turn
   this feature on looks something like this:

	qemu-system-s390x ... -cpu xxx,ap=on ...

   This feature will be supported for zEC12 and newer CPU models.
   The feature will not be supported for older models because
   there are few older systems on which to test and the older
   crypto cards will be going out of service in the relatively
   near future.

CPU model facilities:

1. The S390_FEAT_AP_QUERY_CONFIG_INFO feature indicates whether the
   AP Query Configuration Information (QCI) facility is available
   to the guest as determined by whether the facility is available
   on the host. This feature will be exposed by KVM only if the
   QCI facility is installed on the host.

2. The S390_FEAT_AP_FACILITY_TEST feature indicates whether the AP
   Facility Test (APFT) facility is available to the guest as
   determined by whether the facility is available on the host.
   This feature will be exposed by KVM only if APFT is installed
   on the host.

Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Tested-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20181010170309.12045-3-akrowiak@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-10-12 11:32:18 +02:00
Christian Borntraeger
27e84d4ebd s390x/kvm: add etoken facility
Provide the etoken facility. We need to handle cpu model, migration and
clear reset.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Message-Id: <20180731090448.36662-3-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-20 14:18:49 +02:00
Michael Mueller
a5f9ecc49d s390x/cpumodel: enum type S390FeatGroup now gets generated
The enumeration type S390FeatGroup is now generated as well.
This shall simplify the definition of new feature groups
without the requirement to modify existing code.

Signed-off-by: Michael Mueller <mimu@linux.ibm.com>
Message-Id: <20180725143617.8731-1-mimu@linux.ibm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-20 14:18:49 +02:00
Christian Borntraeger
8727315111 s390x/cpumodel: default enable bpb and ppa15 for z196 and later
Most systems and host kernels provide the necessary building blocks for
bpb and ppa15. We can reverse the logic and default enable those
features, while still allowing to disable it via cpu model.

So let us add bpb and ppa15 to z196 and later default CPU model for the
qemu 3.0 machine. (like -cpu z13).  Older machine types (e.g.
s390-ccw-virtio-2.12) will retain the old value and not provide those
bits in the default model.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180626123830.18282-1-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02 10:37:38 +02:00
Peter Maydell
7e0019a719 Miscellaneous patches for 2018-02-07
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJafZmjAAoJEDhwtADrkYZTuvkP/i8gYzquYW/8u0XiGjQdi0VM
 cZzxqLe9DSxfjRO9p0D11uLQmw3js8z60mi++1NOhtYTn4P/htsgXLrrxrLS8U0I
 b+mD6LeqGN2miCKWy4X/w52S0krW05ROJMb/s+OQP7aJu/OA+t6QXM6jzIPOnFa+
 GrxFesOizvjLVONvmI8nbUKXayJ77rB8ctsuCjmbMO1XkxMLPWLchduswFH7ywbL
 ZJwUK3v1x+R0Apvy7y4f8e6aamreABtAjuD53zoS1PmLfZ4dvgYVJkhimIGsVjpA
 8AGCbazsIWl7YLJ2dghXaVE2gwV3LrwTPhoF0YeSjrJ2f4TE7NPCaPZW3C9yTtQC
 YEiD4cG5HNE7HhBRIImmTvOGU7sSmYwJQ4+5yGKtJGlBGRSbYP2upWf3nEsOnGPx
 TkdcsEPQHEP/YuJlZpO4jfdUiBAQsbmyY3xnMvdpfhDJRGSB7UwQ1xTgmjIXOr15
 6Zv4NaWB0JInGhoEAra4Jdld3fJ0Nh+XAXITAPogppipvxmIYz9AxZTjhu0cQWX6
 dDvk3FSOuC8Y+r/6UxQkAwCNAld+GilAABgHtXQjx8b8ySlE98EKuvcmPaH4pemC
 K0YoRF32rIoDLbh6xg++ior7+eABrk9STlqCI/3SSEgDr0loTyXnI5KBBNoz+Jjw
 AU2c5RYvNOqEGT42bL/C
 =DMbf
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2018-02-07-v4' into staging

Miscellaneous patches for 2018-02-07

# gpg: Signature made Fri 09 Feb 2018 12:52:51 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-misc-2018-02-07-v4:
  Move include qemu/option.h from qemu-common.h to actual users
  Drop superfluous includes of qapi/qmp/qjson.h
  Drop superfluous includes of qapi/qmp/dispatch.h
  Include qapi/qmp/qnull.h exactly where needed
  Include qapi/qmp/qnum.h exactly where needed
  Include qapi/qmp/qbool.h exactly where needed
  Include qapi/qmp/qstring.h exactly where needed
  Include qapi/qmp/qdict.h exactly where needed
  Include qapi/qmp/qlist.h exactly where needed
  Include qapi/qmp/qobject.h exactly where needed
  qdict qlist: Make most helper macros functions
  Eliminate qapi/qmp/types.h
  Typedef the subtypes of QObject in qemu/typedefs.h, too
  Include qmp-commands.h exactly where needed
  Drop superfluous includes of qapi/qmp/qerror.h
  Include qapi/error.h exactly where needed
  Drop superfluous includes of qapi-types.h and test-qapi-types.h
  Clean up includes
  Use #include "..." for our own headers, <...> for others
  vnc: use stubs for CONFIG_VNC=n dummy functions

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-09 14:39:09 +00:00
David Hildenbrand
46a99c9f73 s390x/cpumodel: model PTFF subfunctions for Multiple-epoch facility
For now, the kernel does not properly indicate configured CPU subfunctions
to the guest, but simply uses the host values (as support in KVM is still
missing). That's why we missed to model the PTFF subfunctions that come
with Multiple-epoch facility.

Let's properly add these, along with a new feature group.

Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180205102935.14736-1-david@redhat.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 09:37:13 +01:00
Cornelia Huck
e3fd586dfa s390x/cpumodel: allow zpci features in qemu model
AEN and AIS can be provided unconditionally, ZPCI should be turned on
manually.

With -cpu qemu,zpci=on, the guest kernel can now successfully detect
virtio-pci devices under tcg.

Also fixup the order of the MSA_EXT_{3,4} flags while at it.

Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 09:37:13 +01:00
Markus Armbruster
d8e39b7062 Use #include "..." for our own headers, <...> for others
System headers should be included with <...>, our own headers with
"...".  Offenders tracked down with an ugly, brittle and probably
buggy Perl script.  Previous iteration was commit a9c94277f0.

Delete inclusions of "string.h" and "strings.h" instead of fixing them
to <string.h> and <strings.h>, because we always include these via
osdep.h.

Put the cleaned up system header includes first.

While there, separate #include from file comment with exactly one
blank line.

Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180201111846.21846-2-armbru@redhat.com>
2018-02-09 05:05:11 +01:00
Christian Borntraeger
9f0d13f4f1 s390x/kvm: provide stfle.81
stfle.81 (ppa15) is a transparent facility that can be passed to the
guest without the need to implement hypervisor support. As this feature
can be provided by firmware we add it to all full models.

Cc: qemu-stable@nongnu.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180118085628.40798-4-borntraeger@de.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22 11:22:43 +01:00
Christian Borntraeger
b073c87517 s390x/kvm: Handle bpb feature
We need to handle the bpb control on reset and migration. Normally
stfle.82 is transparent (and the normal guest part works without
hypervisor activity). To prevent any issues we require full
host kernel support for this feature.

Cc: qemu-stable@nongnu.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180118085628.40798-3-borntraeger@de.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
[CH: 'Branch Prediction Blocking' -> 'Branch prediction blocking']
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22 11:22:30 +01:00
David Hildenbrand
35b4df6417 s390x: change the QEMU cpu model to a stripped down z12
We are good enough to boot upstream Linux kernels / Fedora 26/27. That
should be sufficient for now.

As the QEMU CPU model is migration safe, let's add compatibility code.
Generate the feature list to reduce the chance of messing things up in the
future.

Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20171208165529.14124-1-david@redhat.com>
[CH: squashed 's390x/cpumodel: make qemu cpu model play with "none" machine'
(20171213132407.5227-1-david@redhat.com) and 's390x/tcg: don't include z13
features in the qemu model' (20171213171512.17601-1-david@redhat.com) into
patch]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14 17:56:54 +01:00
Christian Borntraeger
9dacc90846 s390x/cpumodel: remove ais from z14 default model-> also for 2.10.1
We disabled ais for 2.10, so let's also remove it from the z14
default model.

Fixes: 3f2d07b3b0 ("s390x/ais: for 2.10 stable: disable ais facility")
CC: qemu-stable@nongnu.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20170927072030.35737-2-borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-09-27 11:13:32 +02:00
Christian Borntraeger
c1b364ffd7 s390/cpumodel: remove KSS from the default model of z14
The SIE_KSS feature will allow a guest to use KSS for a nested guest.
To create a nested guest the SIE_F2 facility is still necessary.
Since SIE_F2 is not part of the default model it does not make
a lot of sense to provide the SIE_KSS feature in the default model.
Let's also create a dependency check.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1500550051-7821-2-git-send-email-borntraeger@de.ibm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-07-25 09:17:42 +02:00
Jason J. Herne
cc28a5949b s390x/cpumodel: z14 cpu models
This patch introduces the CPU model for z14, along with all base and
optional features.

Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-07-18 10:55:16 +02:00
Jason J. Herne
7223bccea3 s390x/cpumodel: add esop/esop2 to z12 model
Add esop and esop2 features to z12 model where esop2 was originally
introduced. Disable esop and esop2 when using compatibility machine
v2.9 or earlier.

Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-07-14 12:29:49 +02:00
Jason J. Herne
6da5c593bb s390x/cpumodel: wire up new hardware features
Some new guest features have been introduced recently. Let's wire
them up in the CPU model.

Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
[split patch]
2017-07-14 12:29:49 +02:00
Yi Min Zhao
3b00f702c2 s390x/cpumodel: add zpci, aen and ais facilities
zPCI instructions and facilities are available since IBM zEnterprise
EC12. To support z/PCI in QEMU we enable zpci, aen and ais facilities
starting with zEC12 GA1. And we always set zpci and aen bits in max cpu
model. Later they might be switched off due to applied real cpu model.
For ais bit, we only provide it in the full cpu model beginning with
zEC12 and defer its enablement in the default cpu model to a later point
in time. At the same time, disable them for 2.9 and older machines.

Because of introducing AIS facility, we could check if it's enabled to
initialize flic->ais_supported with the real value.

Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2017-07-14 12:29:49 +02:00
Jason J. Herne
ec3aadb13e s390x/cpumodel: clean up spacing and comments
Clean up spacing and add comments to clarify difference between base, full and
default models.

Not having spacing around the model definitions in gen-features.c is
particularly frustrating as the reader tends to misinterpret which model they
are looking at or editing.

Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-07-14 12:29:47 +02:00
Thomas Huth
fcf5ef2ab5 Move target-* CPU file into a target/ folder
We've currently got 18 architectures in QEMU, and thus 18 target-xxx
folders in the root folder of the QEMU source tree. More architectures
(e.g. RISC-V, AVR) are likely to be included soon, too, so the main
folder of the QEMU sources slowly gets quite overcrowded with the
target-xxx folders.
To disburden the main folder a little bit, let's move the target-xxx
folders into a dedicated target/ folder, so that target-xxx/ simply
becomes target/xxx/ instead.

Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part]
Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part]
Acked-by: Michael Walle <michael@walle.cc> [lm32 part]
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part]
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part]
Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part]
Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part]
Acked-by: Richard Henderson <rth@twiddle.net> [alpha part]
Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part]
Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part]
Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part]
Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part]
Signed-off-by: Thomas Huth <thuth@redhat.com>
2016-12-20 21:52:12 +01:00