On 07/02/2018 12:28 PM, Cornelia Huck wrote:
On Mon, 2 Jul 2018 18:20:55 +0200
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
On 07/02/2018 06:11 PM, Cornelia Huck wrote:
On Mon, 2 Jul 2018 11:54:28 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
On 07/02/2018 11:41 AM, Cornelia Huck wrote:
On Mon, 2 Jul 2018 11:37:11 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
On 07/02/2018 10:38 AM, Christian Borntraeger wrote:
On 06/29/2018 11:11 PM, Tony Krowiak wrote:
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. This facility
must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
feature is not installed.
If this facility is not set for the KVM guest, then only
APQNs with an APQI less than 16 will be available to the
guest regardless of the guest's matrix configuration. This
is a limitation of the AP bus running on the guest.
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. This facility
must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
feature is not installed.
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. This is a limitation
of the AP bus running under the guest.
Reviewed-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
Reviewed-by: Halil Pasic <pasic@xxxxxxxxxxxxx>
Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
I think it probably should be at the end of the series, other than that its good.
If I move this to the end of the series, the very next patch checks the
KVM_S390_VM_CPU_FEAT_AP feature?
Introduce it here, offer it only with the last patch?
I apologize, but I don't know what you mean by this. Are you suggesting
this patch
should only include the #define for KVM_S390_VM_CPU_FEAT_AP?
Yes, just introduce the definition here (so code later in the series
can refer to it) and flip the switch (offer the bit) as the final
patch.
The other features introduced and exposed here are no different. For
KVM_S390_VM_CPU_FEAT_AP defer exposing means defer allow_cpu_feat();
for the STFLE features, defer adding to FACILITIES_KVM_CPUMODEL.
Anyway, I think the definition should be squashed into #6. Expose the
features after patch #6 is in place or expose them at the end of the
series is IMHO a matter of taste -- and I lean towards expose at the
end of the series.
Squashing with patch 6 and enabling at the end of the series sounds
good to me as well.
Consider it done.
