summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorDavid Hildenbrand <dahi@linux.vnet.ibm.com>2016-05-18 14:03:47 (GMT)
committerChristian Borntraeger <borntraeger@de.ibm.com>2016-06-10 10:07:17 (GMT)
commit0a763c780b7cb830c250d00ead975778ab948f40 (patch)
treef7d7448dcaf8f74032a55dadc21db3f4ec4958e9 /.mailmap
parent1afd43e0fbba4a92effc22977e3a7e64213ee860 (diff)
downloadlinux-0a763c780b7cb830c250d00ead975778ab948f40.tar.xz
KVM: s390: interface to query and configure cpu subfunctions
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 <dahi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions