Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP virtualization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/22/2018 07:19 AM, David Hildenbrand wrote:
On 13.08.2018 23:48, Tony Krowiak wrote:
From: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>

Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.

CPU model feature:

The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP instructions are available on the guest. This
feature will be enabled by the kernel only if the AP
instructions are installed on the linux host. This feature
must be specifically turned on for the KVM guest from
userspace to use the VFIO AP device driver for guest
access to AP devices.

CPU model facilities:

1. AP Query Configuration Information (QCI) facility is installed.

    This is indicated by setting facilities bit 12 for
    the guest. The kernel will not enable this facility
    for the guest if it is not set on the host.

    If this facility is not set for the KVM guest, then only
    APQNs with an APQI less than 16 will be used by a Linux
    guest regardless of the matrix configuration for the virtual
    machine. This is a limitation of the Linux AP bus.

2. AP Facilities Test facility (APFT) is installed.

    This is indicated by setting facilities bit 15 for
    the guest. The kernel will not enable this facility for
    the guest if it is not set on the host.

    If this facility is not set for the KVM guest, then no
    AP devices will be available to the guest regardless of
    the guest's matrix configuration for the virtual
    machine. This is a limitation of the Linux AP bus.

Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
Reviewed-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
Reviewed-by: Halil Pasic <pasic@xxxxxxxxxxxxx>
Tested-by: Michael Mueller <mimu@xxxxxxxxxxxxx>
Tested-by: Farhan Ali <alifm@xxxxxxxxxxxxx>
Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
---
  arch/s390/kvm/kvm-s390.c         |    5 +++++
  arch/s390/tools/gen_facilities.c |    2 ++
  2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 1e8cb67..d5e04d2 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -367,6 +367,11 @@ static void kvm_s390_cpu_feat_init(void)
if (MACHINE_HAS_ESOP)
  		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
+
+	/* Check if AP instructions installed on host */
+	if (ap_instructions_available())
+		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
+
  	/*
  	 * We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
  	 * 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 90a8c9e..a52290b 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -106,6 +106,8 @@ struct facility_def {
.name = "FACILITIES_KVM_CPUMODEL",
  		.bits = (int[]){
+			12, /* AP Query Configuration Information */
+			15, /* AP Facilities Test */
  			-1  /* END */
  		}
  	},

I really wonder if we should also export the APXA facility.

Given this comment is made within the context of the
FACILITIES_KVM_CPUMODEL I might point out that APXA is not
indicated by a facilities bit. It is indicated by a bit in
the QCI control block returned from the PQAP(QCI)
instruction to indicate that APXA is installed on all CPUs.

We can probe and allow that CPU feature. However, we cannot disable it
(as of now).

Given this patch series implements passthrough devices,
the output of the PQAP(QCI) will always be from a real
device - i.e., there will be no way to disable it.


We have other CPU features where it is the same case (basically all
subfunctions). See kvm_s390_get_processor_subfunc(). We probe them and
export them, but support to disable them has never been implemented.

On a high level, we could then e.g. deny to start a QEMU guest if APXA
is available but has been disabled. (until we know that disabling it
actually works - if ever).

This helps to catch nasty migration bugs (e.g. APXA suddenly
disappearing). Although unlikely, definitely possible.

Migration of AP devices is not supported by this patch series, so this should
not be an issue.



Are there any other AP related facilities that the guest can from now on
probe that should also become part of the CPU model?





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux