Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On Wed, 6 Dec 2017 10:15:51 +0100 Pierre Morel wrote: > On 05/12/2017 16:01, Tony Krowiak wrote: > > On 12/05/2017 09:04 AM, Cornelia Huck wrote: > >> On Tue, 5 Dec 2017 08:52:57 +0100 > >> Harald Freudenberger wrote: > >> > >>> On 12/02/2017 02:30 AM, Tony Krowiak wrote: > I agree with your suggestion that defining a new CPU model feature > is probably > the best way to resolve this issue. The question is, should we > define a single > feature indicating whether AP instructions are installed and set > features bits > for the guest based on whether or not they are set in the linux > host, or should > we define additional CPU model features for turning features bits on > and off? > I guess it boils down to what behavior is expected for the AP bus > running on > the linux guest. Here is a rundown of the facilities bits associated > with AP > and how they affect the behavior of the AP bus: > > * STFLE.12 indicates whether the AP query function is available. If > this bit > is not set, then the AP bus scan will only test domains 0-15. For > example, > if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are > installed, then AP > queues 04.0047, 05.0047 and 06.0047 will not be made available. > >>> STFLE 12 is the indication for Query AP Configuration Information > >>> (QCI) available. > * STFLE.15 indicates whether the AP facilities test function is > available. If > this bit is not set, then the CEX4, CEX5 and CEX6 device drivers > discovered > by the AP bus scan will not get bound to any AP device drivers. > Since the > AP matrix model supports only CEX4 and greater, no devices will > be bound > to any driver for a guest. > >>> This T-Bit extension to the TAPQ subfunction is a must have. When kvm > >>> only > >>> supports CEX4 and upper then this bit could also act as the indicator > >>> for > >>> AP instructions available. Of course if you want to implement pure > >>> virtual > >>> full simulated AP without any real AP hardware on the host this bit > >>> can't > >>> be the indicator. > >> It would probably make sense to group these two together. Or is there > >> any advantage in supporting only a part of it? > > After thinking about this a little more, I've come to the conclusion that > > all of this might be moot for the following reasons: > > > > * If STFLE.12 is not set for the linux host, then AP bus scan running on > > the host will not detect any domains with a domain number higher than > > 15, > > so no AP queues with a queue index higher than 15 will be available to > > bind to the vfio_ap_matrix driver. Consequently, no domain higher than > > 15 can be assigned to any guest. In this case, the AP bus scan > > running on > > the guest will never detect a domain higher than 15, regardless of the > > setting of STFLE.12 for the guest. > > > > * If STFLE.15 is not set for the linux host, then then there will be no > > CEX4, CEX5 or CEX6 queues available to bind to the vfio_ap_matrix > > driver, so no AP adapters or domains can be assigned to any KVM guest. > > > > The bottom line is the STFLE bit settings for the linux host will control > > what APs are available to the KVM guest. Since STFLE.15 controls whether > > any CEX4,5 or 6 devices are even available, I think this bit can be > > combined into the feature that indicates whether AP is available. As long > > as AP instructions are available on the linux host, I'm not sure whether > > STFLE.12 needs a feature at all. > > We are implementing VFIO with SIE interpretation. > > 1) Providing more: > The simple way is to provide to the guest only features existing on the > host. > If we do provide features not existing on the host we need to be able to > emulate them. > Even it is possible, it could be done in a future enhancement, but AFAIK > it is not the goal of the current development. Yes. I think we currently want to provide a subset of what the SIE can do. Any emulation would be icing on top. > > 2) Providing less: > On the other hand we can mask to the guest some of the features provided > by the host if we can intercept the scanning of the features. Yes. I think that applies to bit 65 (interrupts) for now. > > > What I understand from this is that we need all these features being > separately toggled to be able to be compatible with an older system even > if we have a 1:1 host:guest features match in a first version. This seems to be the case for the mentioned bits if I followed the discussion correctly. > > If several features where introduced together in a new architecture and > are available on all systems issued from this architecture we can then > gather them in a set. (But I will wonder why we have several features then) You're expecting that all architecture is making sens
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 05/12/2017 16:01, Tony Krowiak wrote: On 12/05/2017 09:04 AM, Cornelia Huck wrote: On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: On 12/02/2017 02:30 AM, Tony Krowiak wrote: I agree with your suggestion that defining a new CPU model feature is probably the best way to resolve this issue. The question is, should we define a single feature indicating whether AP instructions are installed and set features bits for the guest based on whether or not they are set in the linux host, or should we define additional CPU model features for turning features bits on and off? I guess it boils down to what behavior is expected for the AP bus running on the linux guest. Here is a rundown of the facilities bits associated with AP and how they affect the behavior of the AP bus: * STFLE.12 indicates whether the AP query function is available. If this bit is not set, then the AP bus scan will only test domains 0-15. For example, if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP queues 04.0047, 05.0047 and 06.0047 will not be made available. STFLE 12 is the indication for Query AP Configuration Information (QCI) available. * STFLE.15 indicates whether the AP facilities test function is available. If this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered by the AP bus scan will not get bound to any AP device drivers. Since the AP matrix model supports only CEX4 and greater, no devices will be bound to any driver for a guest. This T-Bit extension to the TAPQ subfunction is a must have. When kvm only supports CEX4 and upper then this bit could also act as the indicator for AP instructions available. Of course if you want to implement pure virtual full simulated AP without any real AP hardware on the host this bit can't be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? After thinking about this a little more, I've come to the conclusion that all of this might be moot for the following reasons: * If STFLE.12 is not set for the linux host, then AP bus scan running on the host will not detect any domains with a domain number higher than 15, so no AP queues with a queue index higher than 15 will be available to bind to the vfio_ap_matrix driver. Consequently, no domain higher than 15 can be assigned to any guest. In this case, the AP bus scan running on the guest will never detect a domain higher than 15, regardless of the setting of STFLE.12 for the guest. * If STFLE.15 is not set for the linux host, then then there will be no CEX4, CEX5 or CEX6 queues available to bind to the vfio_ap_matrix driver, so no AP adapters or domains can be assigned to any KVM guest. The bottom line is the STFLE bit settings for the linux host will control what APs are available to the KVM guest. Since STFLE.15 controls whether any CEX4,5 or 6 devices are even available, I think this bit can be combined into the feature that indicates whether AP is available. As long as AP instructions are available on the linux host, I'm not sure whether STFLE.12 needs a feature at all. We are implementing VFIO with SIE interpretation. 1) Providing more: The simple way is to provide to the guest only features existing on the host. If we do provide features not existing on the host we need to be able to emulate them. Even it is possible, it could be done in a future enhancement, but AFAIK it is not the goal of the current development. 2) Providing less: On the other hand we can mask to the guest some of the features provided by the host if we can intercept the scanning of the features. What I understand from this is that we need all these features being separately toggled to be able to be compatible with an older system even if we have a 1:1 host:guest features match in a first version. If several features where introduced together in a new architecture and are available on all systems issued from this architecture we can then gather them in a set. (But I will wonder why we have several features then) * STFLE.65 indicates whether AP interrupts are available. If this bit is not set, then the AP bus will use polling instead of using interrupt handlers to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. Yes, this indicates AP interrupts only. The plan is to enable this when GISA is available and we can implement interrupt processing. If we want to be able to work on system where STFLE.65 is not available, even if GISA is available I think it would be interesting to have a Matrix implementation with only polling. Regards, Pierre -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 12/05/2017 09:23 AM, Pierre Morel wrote: On 05/12/2017 15:04, Cornelia Huck wrote: On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: On 12/02/2017 02:30 AM, Tony Krowiak wrote: I agree with your suggestion that defining a new CPU model feature is probably the best way to resolve this issue. The question is, should we define a single feature indicating whether AP instructions are installed and set features bits for the guest based on whether or not they are set in the linux host, or should we define additional CPU model features for turning features bits on and off? I guess it boils down to what behavior is expected for the AP bus running on the linux guest. Here is a rundown of the facilities bits associated with AP and how they affect the behavior of the AP bus: * STFLE.12 indicates whether the AP query function is available. If this bit is not set, then the AP bus scan will only test domains 0-15. For example, if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP queues 04.0047, 05.0047 and 06.0047 will not be made available. STFLE 12 is the indication for Query AP Configuration Information (QCI) available. * STFLE.15 indicates whether the AP facilities test function is available. If this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered by the AP bus scan will not get bound to any AP device drivers. Since theI think STFLE.12 AP matrix model supports only CEX4 and greater, no devices will be bound to any driver for a guest. This T-Bit extension to the TAPQ subfunction is a must have. When kvm only supports CEX4 and upper then this bit could also act as the indicator for AP instructions available. Of course if you want to implement pure virtual full simulated AP without any real AP hardware on the host this bit can't be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? * STFLE.65 indicates whether AP interrupts are available. If this bit is not set, then the AP bus will use polling instead of using interrupt handlers to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. Yes, STFLE 65, it is for AP only. QCI, STFLE 12, is no present on older systems, in this case AP uses TAPQ to retrieve information for each AP So for my point of view, it make sense to separate the three facilities to enable migration on older syste In the interest of keeping things simple, this makes sense. Pierre
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 12/05/2017 09:04 AM, Cornelia Huck wrote: On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: On 12/02/2017 02:30 AM, Tony Krowiak wrote: I agree with your suggestion that defining a new CPU model feature is probably the best way to resolve this issue. The question is, should we define a single feature indicating whether AP instructions are installed and set features bits for the guest based on whether or not they are set in the linux host, or should we define additional CPU model features for turning features bits on and off? I guess it boils down to what behavior is expected for the AP bus running on the linux guest. Here is a rundown of the facilities bits associated with AP and how they affect the behavior of the AP bus: * STFLE.12 indicates whether the AP query function is available. If this bit is not set, then the AP bus scan will only test domains 0-15. For example, if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP queues 04.0047, 05.0047 and 06.0047 will not be made available. STFLE 12 is the indication for Query AP Configuration Information (QCI) available. * STFLE.15 indicates whether the AP facilities test function is available. If this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered by the AP bus scan will not get bound to any AP device drivers. Since the AP matrix model supports only CEX4 and greater, no devices will be bound to any driver for a guest. This T-Bit extension to the TAPQ subfunction is a must have. When kvm only supports CEX4 and upper then this bit could also act as the indicator for AP instructions available. Of course if you want to implement pure virtual full simulated AP without any real AP hardware on the host this bit can't be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? After thinking about this a little more, I've come to the conclusion that all of this might be moot for the following reasons: * If STFLE.12 is not set for the linux host, then AP bus scan running on the host will not detect any domains with a domain number higher than 15, so no AP queues with a queue index higher than 15 will be available to bind to the vfio_ap_matrix driver. Consequently, no domain higher than 15 can be assigned to any guest. In this case, the AP bus scan running on the guest will never detect a domain higher than 15, regardless of the setting of STFLE.12 for the guest. * If STFLE.15 is not set for the linux host, then then there will be no CEX4, CEX5 or CEX6 queues available to bind to the vfio_ap_matrix driver, so no AP adapters or domains can be assigned to any KVM guest. The bottom line is the STFLE bit settings for the linux host will control what APs are available to the KVM guest. Since STFLE.15 controls whether any CEX4,5 or 6 devices are even available, I think this bit can be combined into the feature that indicates whether AP is available. As long as AP instructions are available on the linux host, I'm not sure whether STFLE.12 needs a feature at all. * STFLE.65 indicates whether AP interrupts are available. If this bit is not set, then the AP bus will use polling instead of using interrupt handlers to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. Yes, this indicates AP interrupts only. The plan is to enable this when GISA is available and we can implement interrupt processing.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 05/12/2017 15:30, Cornelia Huck wrote: On Tue, 5 Dec 2017 15:23:50 +0100 Pierre Morel wrote: On 05/12/2017 15:04, Cornelia Huck wrote: On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: On 12/02/2017 02:30 AM, Tony Krowiak wrote: I agree with your suggestion that defining a new CPU model feature is probably the best way to resolve this issue. The question is, should we define a single feature indicating whether AP instructions are installed and set features bits for the guest based on whether or not they are set in the linux host, or should we define additional CPU model features for turning features bits on and off? I guess it boils down to what behavior is expected for the AP bus running on the linux guest. Here is a rundown of the facilities bits associated with AP and how they affect the behavior of the AP bus: * STFLE.12 indicates whether the AP query function is available. If this bit is not set, then the AP bus scan will only test domains 0-15. For example, if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP queues 04.0047, 05.0047 and 06.0047 will not be made available. STFLE 12 is the indication for Query AP Configuration Information (QCI) available. * STFLE.15 indicates whether the AP facilities test function is available. If this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered by the AP bus scan will not get bound to any AP device drivers. Since the AP matrix model supports only CEX4 and greater, no devices will be bound to any driver for a guest. This T-Bit extension to the TAPQ subfunction is a must have. When kvm only supports CEX4 and upper then this bit could also act as the indicator for AP instructions available. Of course if you want to implement pure virtual full simulated AP without any real AP hardware on the host this bit can't be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? * STFLE.65 indicates whether AP interrupts are available. If this bit is not set, then the AP bus will use polling instead of using interrupt handlers to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. Yes, STFLE 65, it is for AP only. QCI, STFLE 12, is no present on older systems, in this case AP uses TAPQ to retrieve information for each AP Dumb question: How old? Machines that are still supported? No idea which machine are supported or not, will ask. What I can say is that I have here a Lpar which does not support QCI. It seems to be a zEC12.2. z13 support it. So for my point of view, it make sense to separate the three facilities to enable migration on older systems. OK, if STFLE 12 might not be present (pending my question above), but STFLE 15 is indeed a must-have, we should split this up. -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On Tue, 5 Dec 2017 15:23:50 +0100 Pierre Morel wrote: > On 05/12/2017 15:04, Cornelia Huck wrote: > > On Tue, 5 Dec 2017 08:52:57 +0100 > > Harald Freudenberger wrote: > > > >> On 12/02/2017 02:30 AM, Tony Krowiak wrote: > > > >>> I agree with your suggestion that defining a new CPU model feature is > >>> probably > >>> the best way to resolve this issue. The question is, should we define a > >>> single > >>> feature indicating whether AP instructions are installed and set features > >>> bits > >>> for the guest based on whether or not they are set in the linux host, or > >>> should > >>> we define additional CPU model features for turning features bits on and > >>> off? > >>> I guess it boils down to what behavior is expected for the AP bus running > >>> on > >>> the linux guest. Here is a rundown of the facilities bits associated with > >>> AP > >>> and how they affect the behavior of the AP bus: > >>> > >>> * STFLE.12 indicates whether the AP query function is available. If this > >>> bit > >>> is not set, then the AP bus scan will only test domains 0-15. For > >>> example, > >>> if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, > >>> then AP > >>> queues 04.0047, 05.0047 and 06.0047 will not be made available. > >> STFLE 12 is the indication for Query AP Configuration Information (QCI) > >> available. > >>> * STFLE.15 indicates whether the AP facilities test function is > >>> available. If > >>> this bit is not set, then the CEX4, CEX5 and CEX6 device drivers > >>> discovered > >>> by the AP bus scan will not get bound to any AP device drivers. Since > >>> the > >>> AP matrix model supports only CEX4 and greater, no devices will be > >>> bound > >>> to any driver for a guest. > >> This T-Bit extension to the TAPQ subfunction is a must have. When kvm only > >> supports CEX4 and upper then this bit could also act as the indicator for > >> AP instructions available. Of course if you want to implement pure virtual > >> full simulated AP without any real AP hardware on the host this bit can't > >> be the indicator. > > > > It would probably make sense to group these two together. Or is there > > any advantage in supporting only a part of it? > > > >>> * STFLE.65 indicates whether AP interrupts are available. If this bit is > >>> not > >>> set, then the AP bus will use polling instead of using interrupt > >>> handlers > >>> to process AP events. > > > > So, does this indicate "adapter interrupts for AP" only? If so, we > > should keep this separate and only enable it when we have the gisa etc. > > ready. > > > > Yes, STFLE 65, it is for AP only. > > QCI, STFLE 12, is no present on older systems, in this case AP uses TAPQ > to retrieve information for each AP Dumb question: How old? Machines that are still supported? > > So for my point of view, it make sense to separate the three facilities > to enable migration on older systems. OK, if STFLE 12 might not be present (pending my question above), but STFLE 15 is indeed a must-have, we should split this up.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 05/12/2017 15:04, Cornelia Huck wrote: On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: On 12/02/2017 02:30 AM, Tony Krowiak wrote: I agree with your suggestion that defining a new CPU model feature is probably the best way to resolve this issue. The question is, should we define a single feature indicating whether AP instructions are installed and set features bits for the guest based on whether or not they are set in the linux host, or should we define additional CPU model features for turning features bits on and off? I guess it boils down to what behavior is expected for the AP bus running on the linux guest. Here is a rundown of the facilities bits associated with AP and how they affect the behavior of the AP bus: * STFLE.12 indicates whether the AP query function is available. If this bit is not set, then the AP bus scan will only test domains 0-15. For example, if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP queues 04.0047, 05.0047 and 06.0047 will not be made available. STFLE 12 is the indication for Query AP Configuration Information (QCI) available. * STFLE.15 indicates whether the AP facilities test function is available. If this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered by the AP bus scan will not get bound to any AP device drivers. Since the AP matrix model supports only CEX4 and greater, no devices will be bound to any driver for a guest. This T-Bit extension to the TAPQ subfunction is a must have. When kvm only supports CEX4 and upper then this bit could also act as the indicator for AP instructions available. Of course if you want to implement pure virtual full simulated AP without any real AP hardware on the host this bit can't be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? * STFLE.65 indicates whether AP interrupts are available. If this bit is not set, then the AP bus will use polling instead of using interrupt handlers to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. Yes, STFLE 65, it is for AP only. QCI, STFLE 12, is no present on older systems, in this case AP uses TAPQ to retrieve information for each AP So for my point of view, it make sense to separate the three facilities to enable migration on older systems. Pierre -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 12/05/2017 02:52 AM, Harald Freudenberger wrote:
On 12/02/2017 02:30 AM, Tony Krowiak wrote:
On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
On 11/02/2017 07:49 PM, Tony Krowiak wrote:
On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
On Fri, 13 Oct 2017 13:39:04 -0400
Tony Krowiak wrote:
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
With this all KVM guests will always have the AP instructions available, no?
In principles I like this approach, but it differs from the way z/VM does
things,
there the guest will get an exception if it tries to execute an AP instruction
if there are no AP devices assigned to the guest. I wonder if there is a reason
why z/VM does it the way it does.
A good question. For LPAR it seems that you have AP instructions even if you
have
no crypto cards.
I don't believe these facilities control whether or not AP instructions will be
available
to the guest.
This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the
enablement.
The ECA.28 bit controls whether instructions are intercepted or interpreted -
i.e., handled via hardware
virtualization. If set, as is done in patch2, then instructions will be
interpreted. I don't see how
that affects enabling or disabling AP instructions, unless we don't set ECA.28,
intercept every instruction
and program check. Am I missing something here?
If we do not set ECA.28 these instructions intercept and we (the hypervisor)
can then
decide what to do. For example we can give an PIC01 operation exception (illegal
instruction) - thats what we do today.
Now: if we want to be able to migrate a guest from a new kernel back to an old
kernel,
there must be a way to disable the new behaviour so that the user can configure
a guest
that does NOT have these 3 instructions. That means, I want to bind the ap
instruction
to a cpu model feature, so that we only enable ECA.28 and the facility bits, if
the
feature is enabled in the CPU model. Otherwise we have no control on what
happens
when the guest issues these instructions.
Imagine what happens if we not do this and you migrate from an identical hw
with an
identical libvirt/qemu but from a new kernel to an old kernel:
The guest boots starts up on the new kernel
guest kernel: drivers/s390/crypto/ap_bus.c ap_module_init ->
ap_instructions_available
checks if the instructions work. They do and now the guest driver assumes that
all
instructions will continue to work.
Now the guest is migrated back to an old kernel
sooner or later the ap_scan_bus kthread will run to scan the bus (or some
crypto operation
is started) and the instruction will be rejected with a PIC01. kernel oops.
There are several scenarios that have to be accounted for, such as:
* Migrating from a linux host where both the KVM/kernel and QEMU support AP
matrix
devices to a guest host where neither the KVM/kernel nor QEMU support AP
matrix
devices;
* Migrating from a linux host where both the KVM/kernel and QEMU support AP
matrix
devices to a guest host where the KVM/kernel does not support AP matrix
devices
but QEMU does;
* Starting a guest on a linux host where QEMU supports AP matrix devices and
the KVM/kernel does not;
* etc.
I agree with your suggestion that defining a new CPU model feature is probably
the best way to resolve this issue. The question is, should we define a
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger wrote: > On 12/02/2017 02:30 AM, Tony Krowiak wrote: > > I agree with your suggestion that defining a new CPU model feature is > > probably > > the best way to resolve this issue. The question is, should we define a > > single > > feature indicating whether AP instructions are installed and set features > > bits > > for the guest based on whether or not they are set in the linux host, or > > should > > we define additional CPU model features for turning features bits on and > > off? > > I guess it boils down to what behavior is expected for the AP bus running on > > the linux guest. Here is a rundown of the facilities bits associated with AP > > and how they affect the behavior of the AP bus: > > > > * STFLE.12 indicates whether the AP query function is available. If this bit > > is not set, then the AP bus scan will only test domains 0-15. For example, > > if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then > > AP > > queues 04.0047, 05.0047 and 06.0047 will not be made available. > STFLE 12 is the indication for Query AP Configuration Information (QCI) > available. > > * STFLE.15 indicates whether the AP facilities test function is available. > > If > > this bit is not set, then the CEX4, CEX5 and CEX6 device drivers > > discovered > > by the AP bus scan will not get bound to any AP device drivers. Since the > > AP matrix model supports only CEX4 and greater, no devices will be bound > > to any driver for a guest. > This T-Bit extension to the TAPQ subfunction is a must have. When kvm only > supports CEX4 and upper then this bit could also act as the indicator for > AP instructions available. Of course if you want to implement pure virtual > full simulated AP without any real AP hardware on the host this bit can't > be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? > > * STFLE.65 indicates whether AP interrupts are available. If this bit is not > > set, then the AP bus will use polling instead of using interrupt handlers > > to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 12/02/2017 02:30 AM, Tony Krowiak wrote:
> On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
>>
>> On 11/02/2017 07:49 PM, Tony Krowiak wrote:
>>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
>> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>>> On Fri, 13 Oct 2017 13:39:04 -0400
>>> Tony Krowiak wrote:
>>>
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c
b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+ 12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+ 15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
>>> With this all KVM guests will always have the AP instructions
>>> available, no?
>>> In principles I like this approach, but it differs from the way z/VM
>>> does things,
>>> there the guest will get an exception if it tries to execute an AP
>>> instruction
>>> if there are no AP devices assigned to the guest. I wonder if there is
>>> a reason
>>> why z/VM does it the way it does.
>> A good question. For LPAR it seems that you have AP instructions even if
>> you have
>> no crypto cards.
>>
> I don't believe these facilities control whether or not AP instructions
> will be available
>
> to the guest.
This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the
enablement.
>>> The ECA.28 bit controls whether instructions are intercepted or interpreted
>>> - i.e., handled via hardware
>>> virtualization. If set, as is done in patch2, then instructions will be
>>> interpreted. I don't see how
>>> that affects enabling or disabling AP instructions, unless we don't set
>>> ECA.28, intercept every instruction
>>> and program check. Am I missing something here?
>> If we do not set ECA.28 these instructions intercept and we (the hypervisor)
>> can then
>> decide what to do. For example we can give an PIC01 operation exception
>> (illegal
>> instruction) - thats what we do today.
>>
>> Now: if we want to be able to migrate a guest from a new kernel back to an
>> old kernel,
>> there must be a way to disable the new behaviour so that the user can
>> configure a guest
>> that does NOT have these 3 instructions. That means, I want to bind the ap
>> instruction
>> to a cpu model feature, so that we only enable ECA.28 and the facility bits,
>> if the
>> feature is enabled in the CPU model. Otherwise we have no control on what
>> happens
>> when the guest issues these instructions.
>>
>> Imagine what happens if we not do this and you migrate from an identical hw
>> with an
>> identical libvirt/qemu but from a new kernel to an old kernel:
>>
>> The guest boots starts up on the new kernel
>> guest kernel: drivers/s390/crypto/ap_bus.c ap_module_init ->
>> ap_instructions_available
>> checks if the instructions work. They do and now the guest driver assumes
>> that all
>> instructions will continue to work.
>>
>> Now the guest is migrated back to an old kernel
>> sooner or later the ap_scan_bus kthread will run to scan the bus (or some
>> crypto operation
>> is started) and the instruction will be rejected with a PIC01. kernel oops.
> There are several scenarios that have to be accounted for, such as:
> * Migrating from a linux host where both the KVM/kernel and QEMU support AP
> matrix
> devices to a
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
On 11/02/2017 07:49 PM, Tony Krowiak wrote:
On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
On Fri, 13 Oct 2017 13:39:04 -0400
Tony Krowiak wrote:
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
With this all KVM guests will always have the AP instructions available, no?
In principles I like this approach, but it differs from the way z/VM does
things,
there the guest will get an exception if it tries to execute an AP instruction
if there are no AP devices assigned to the guest. I wonder if there is a reason
why z/VM does it the way it does.
A good question. For LPAR it seems that you have AP instructions even if you
have
no crypto cards.
I don't believe these facilities control whether or not AP instructions will be
available
to the guest.
This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the
enablement.
The ECA.28 bit controls whether instructions are intercepted or interpreted -
i.e., handled via hardware
virtualization. If set, as is done in patch2, then instructions will be
interpreted. I don't see how
that affects enabling or disabling AP instructions, unless we don't set ECA.28,
intercept every instruction
and program check. Am I missing something here?
If we do not set ECA.28 these instructions intercept and we (the hypervisor)
can then
decide what to do. For example we can give an PIC01 operation exception (illegal
instruction) - thats what we do today.
Now: if we want to be able to migrate a guest from a new kernel back to an old
kernel,
there must be a way to disable the new behaviour so that the user can configure
a guest
that does NOT have these 3 instructions. That means, I want to bind the ap
instruction
to a cpu model feature, so that we only enable ECA.28 and the facility bits, if
the
feature is enabled in the CPU model. Otherwise we have no control on what
happens
when the guest issues these instructions.
Imagine what happens if we not do this and you migrate from an identical hw
with an
identical libvirt/qemu but from a new kernel to an old kernel:
The guest boots starts up on the new kernel
guest kernel: drivers/s390/crypto/ap_bus.c ap_module_init ->
ap_instructions_available
checks if the instructions work. They do and now the guest driver assumes that
all
instructions will continue to work.
Now the guest is migrated back to an old kernel
sooner or later the ap_scan_bus kthread will run to scan the bus (or some
crypto operation
is started) and the instruction will be rejected with a PIC01. kernel oops.
There are several scenarios that have to be accounted for, such as:
* Migrating from a linux host where both the KVM/kernel and QEMU support
AP matrix
devices to a guest host where neither the KVM/kernel nor QEMU support
AP matrix
devices;
* Migrating from a linux host where both the KVM/kernel and QEMU support
AP matrix
devices to a guest host where the KVM/kernel does not support AP
matrix devices
but QEMU does;
* Starting a guest on a linux host where QEMU supports AP matrix devices
and
the KVM/kernel does not;
* etc.
I agree with your suggestion that defining a new CPU model feature is
probably
the best way to resolve this issue. The question is, should we define a
single
feature indicating whether AP instructions are installed and set
features bits
for the guest based on whe
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/03/2017 09:14 AM, Harald Freudenberger wrote: > I talked with the firmware guys about this. > The answer is that the AP 3 instructions (NQAP, DQAP, PQAP) are always > available. That is true for basic mode and LPAR, but certainly not for z/VM or KVM guests. > Tony is right with the facility bits. > facility bit 15 tells if the T bit is supported with the PQAP(TAPQ) > subcommand, > facility bit 12 tells if the PQAP(QCI) subcommand is available. > > As far as I could discover the AP instructions where optional on some older > machines. > This may be the reason why zVM throws an exception if there is no AP device > assigned. > However, for all machines still in service the AP instructions are available > at al time. We have to distinguish LPARs and 2nd level guests under KVM/z/VM. For those 2nd level guests there are configurations out there TODAY that do not support PQAP and friends.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/02/2017 07:49 PM, Tony Krowiak wrote:
> On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
>>
>> On 11/02/2017 04:36 PM, Tony Krowiak wrote:
>>> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
> On Fri, 13 Oct 2017 13:39:04 -0400
> Tony Krowiak wrote:
>
>> Sets up the following facilities bits to enable the specified AP
>> facilities for the guest VM:
>> * STFLE.12: Enables the AP Query Configuration Information
>> facility. The AP bus running in the guest uses
>> the information returned from this instruction
>> to configure AP adapters and domains for the
>> guest machine.
>> * STFLE.15: Indicates the AP facilities test is available.
>> The AP bus running in the guest uses the
>> information.
>>
>> Signed-off-by: Tony Krowiak
>> ---
>> arch/s390/tools/gen_facilities.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/s390/tools/gen_facilities.c
>> b/arch/s390/tools/gen_facilities.c
>> index 70dd8f1..eeaa7db 100644
>> --- a/arch/s390/tools/gen_facilities.c
>> +++ b/arch/s390/tools/gen_facilities.c
>> @@ -74,8 +74,10 @@ struct facility_def {
>> 8, /* enhanced-DAT 1 */
>> 9, /* sense-running-status */
>> 10, /* conditional sske */
>> + 12, /* AP query configuration */
>> 13, /* ipte-range */
>> 14, /* nonquiescing key-setting */
>> + 15, /* AP special-command facility */
>> 73, /* transactional execution */
>> 75, /* access-exception-fetch/store indication */
>> 76, /* msa extension 3 */
> With this all KVM guests will always have the AP instructions available,
> no?
> In principles I like this approach, but it differs from the way z/VM does
> things,
> there the guest will get an exception if it tries to execute an AP
> instruction
> if there are no AP devices assigned to the guest. I wonder if there is a
> reason
> why z/VM does it the way it does.
A good question. For LPAR it seems that you have AP instructions even if
you have
no crypto cards.
>>> I don't believe these facilities control whether or not AP instructions
>>> will be available
>>>
>>> to the guest.
>> This is actually handled by your patch2 enabling the ECA bit.
>> I think we must decide if we want to be able to disable these instructions
>> via the cpu model. If yes we must then couple the facilities with the
>> enablement.
> The ECA.28 bit controls whether instructions are intercepted or interpreted -
> i.e., handled via hardware
> virtualization. If set, as is done in patch2, then instructions will be
> interpreted. I don't see how
> that affects enabling or disabling AP instructions, unless we don't set
> ECA.28, intercept every instruction
> and program check. Am I missing something here?
If we do not set ECA.28 these instructions intercept and we (the hypervisor)
can then
decide what to do. For example we can give an PIC01 operation exception (illegal
instruction) - thats what we do today.
Now: if we want to be able to migrate a guest from a new kernel back to an old
kernel,
there must be a way to disable the new behaviour so that the user can configure
a guest
that does NOT have these 3 instructions. That means, I want to bind the ap
instruction
to a cpu model feature, so that we only enable ECA.28 and the facility bits, if
the
feature is enabled in the CPU model. Otherwise we have no control on what
happens
when the guest issues these instructions.
Imagine what happens if we not do this and you migrate from an identical hw
with an
identical libvirt/qemu but from a new kernel to an old kernel:
The guest boots starts up on the new kernel
guest kernel: drivers/s390/crypto/ap_bus.c ap_module_init ->
ap_instructions_available
checks if the instructions work. They do and now the guest driver assumes that
all
instructions will continue to work.
Now the guest is migrated back to an old kernel
sooner or later the ap_scan_bus kthread will run to scan the bus (or some
crypto operation
is started) and the instruction will be rejected with a PIC01. kernel oops.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
On Fri, 13 Oct 2017 13:39:04 -0400
Tony Krowiak wrote:
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+ 12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+ 15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
With this all KVM guests will always have the AP instructions available, no?
In principles I like this approach, but it differs from the way z/VM does
things,
there the guest will get an exception if it tries to execute an AP instruction
if there are no AP devices assigned to the guest. I wonder if there is a reason
why z/VM does it the way it does.
A good question. For LPAR it seems that you have AP instructions even if you
have
no crypto cards.
I don't believe these facilities control whether or not AP instructions will be
available
to the guest.
This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the
enablement.
The ECA.28 bit controls whether instructions are intercepted or
interpreted - i.e., handled via hardware
virtualization. If set, as is done in patch2, then instructions will be
interpreted. I don't see how
that affects enabling or disabling AP instructions, unless we don't set
ECA.28, intercept every instruction
and program check. Am I missing something here?
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
>>
>> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>>> On Fri, 13 Oct 2017 13:39:04 -0400
>>> Tony Krowiak wrote:
>>>
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c
b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+ 12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+ 15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
>>> With this all KVM guests will always have the AP instructions available, no?
>>> In principles I like this approach, but it differs from the way z/VM does
>>> things,
>>> there the guest will get an exception if it tries to execute an AP
>>> instruction
>>> if there are no AP devices assigned to the guest. I wonder if there is a
>>> reason
>>> why z/VM does it the way it does.
>> A good question. For LPAR it seems that you have AP instructions even if you
>> have
>> no crypto cards.
>>
> I don't believe these facilities control whether or not AP instructions will
> be available
>
> to the guest.
This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the
enablement.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 11/02/2017 01:08 PM, Christian Borntraeger wrote:
>
>
> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>> On Fri, 13 Oct 2017 13:39:04 -0400
>> Tony Krowiak wrote:
>>
>>> Sets up the following facilities bits to enable the specified AP
>>> facilities for the guest VM:
>>> * STFLE.12: Enables the AP Query Configuration Information
>>> facility. The AP bus running in the guest uses
>>> the information returned from this instruction
>>> to configure AP adapters and domains for the
>>> guest machine.
>>> * STFLE.15: Indicates the AP facilities test is available.
>>> The AP bus running in the guest uses the
>>> information.
>>>
>>> Signed-off-by: Tony Krowiak
>>> ---
>>> arch/s390/tools/gen_facilities.c |2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/s390/tools/gen_facilities.c
>>> b/arch/s390/tools/gen_facilities.c
>>> index 70dd8f1..eeaa7db 100644
>>> --- a/arch/s390/tools/gen_facilities.c
>>> +++ b/arch/s390/tools/gen_facilities.c
>>> @@ -74,8 +74,10 @@ struct facility_def {
>>> 8, /* enhanced-DAT 1 */
>>> 9, /* sense-running-status */
>>> 10, /* conditional sske */
>>> + 12, /* AP query configuration */
>>> 13, /* ipte-range */
>>> 14, /* nonquiescing key-setting */
>>> + 15, /* AP special-command facility */
>>> 73, /* transactional execution */
>>> 75, /* access-exception-fetch/store indication */
>>> 76, /* msa extension 3 */
>>
>> With this all KVM guests will always have the AP instructions available, no?
>> In principles I like this approach, but it differs from the way z/VM does
>> things,
>> there the guest will get an exception if it tries to execute an AP
>> instruction
>> if there are no AP devices assigned to the guest. I wonder if there is a
>> reason
>> why z/VM does it the way it does.
>
> A good question. For LPAR it seems that you have AP instructions even if you
> have
> no crypto cards.
>
I've tried to figure these things out last week but I've failed.
Right at the beginning of AR-10334-03-POK we have this text:
"An adjunct processor (AP) facility consists of the three AP
instructions, and one to sixty-four APs.". This reads like if we
have AP facility we have to have at least one AP.
But when I've tried to get a better understanding how the
presence/absence of the AP facility is indicated and what facility
bits do we have in this context I got confused.
Tony, could you please give us a detailed summary on this (best with
references, and focusing on the (guest) program perspective)?
Regards,
Halil
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
> On Fri, 13 Oct 2017 13:39:04 -0400
> Tony Krowiak wrote:
>
>> Sets up the following facilities bits to enable the specified AP
>> facilities for the guest VM:
>> * STFLE.12: Enables the AP Query Configuration Information
>> facility. The AP bus running in the guest uses
>> the information returned from this instruction
>> to configure AP adapters and domains for the
>> guest machine.
>> * STFLE.15: Indicates the AP facilities test is available.
>> The AP bus running in the guest uses the
>> information.
>>
>> Signed-off-by: Tony Krowiak
>> ---
>> arch/s390/tools/gen_facilities.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/s390/tools/gen_facilities.c
>> b/arch/s390/tools/gen_facilities.c
>> index 70dd8f1..eeaa7db 100644
>> --- a/arch/s390/tools/gen_facilities.c
>> +++ b/arch/s390/tools/gen_facilities.c
>> @@ -74,8 +74,10 @@ struct facility_def {
>> 8, /* enhanced-DAT 1 */
>> 9, /* sense-running-status */
>> 10, /* conditional sske */
>> +12, /* AP query configuration */
>> 13, /* ipte-range */
>> 14, /* nonquiescing key-setting */
>> +15, /* AP special-command facility */
>> 73, /* transactional execution */
>> 75, /* access-exception-fetch/store indication */
>> 76, /* msa extension 3 */
>
> With this all KVM guests will always have the AP instructions available, no?
> In principles I like this approach, but it differs from the way z/VM does
> things,
> there the guest will get an exception if it tries to execute an AP instruction
> if there are no AP devices assigned to the guest. I wonder if there is a
> reason
> why z/VM does it the way it does.
A good question. For LPAR it seems that you have AP instructions even if you
have
no crypto cards.
Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest
On Fri, 13 Oct 2017 13:39:04 -0400
Tony Krowiak wrote:
> Sets up the following facilities bits to enable the specified AP
> facilities for the guest VM:
> * STFLE.12: Enables the AP Query Configuration Information
> facility. The AP bus running in the guest uses
> the information returned from this instruction
> to configure AP adapters and domains for the
> guest machine.
> * STFLE.15: Indicates the AP facilities test is available.
> The AP bus running in the guest uses the
> information.
>
> Signed-off-by: Tony Krowiak
> ---
> arch/s390/tools/gen_facilities.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/s390/tools/gen_facilities.c
> b/arch/s390/tools/gen_facilities.c
> index 70dd8f1..eeaa7db 100644
> --- a/arch/s390/tools/gen_facilities.c
> +++ b/arch/s390/tools/gen_facilities.c
> @@ -74,8 +74,10 @@ struct facility_def {
> 8, /* enhanced-DAT 1 */
> 9, /* sense-running-status */
> 10, /* conditional sske */
> + 12, /* AP query configuration */
> 13, /* ipte-range */
> 14, /* nonquiescing key-setting */
> + 15, /* AP special-command facility */
> 73, /* transactional execution */
> 75, /* access-exception-fetch/store indication */
> 76, /* msa extension 3 */
With this all KVM guests will always have the AP instructions available, no?
In principles I like this approach, but it differs from the way z/VM does
things,
there the guest will get an exception if it tries to execute an AP instruction
if there are no AP devices assigned to the guest. I wonder if there is a reason
why z/VM does it the way it does.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
[RFC 19/19] s390/facilities: enable AP facilities needed by guest
Sets up the following facilities bits to enable the specified AP
facilities for the guest VM:
* STFLE.12: Enables the AP Query Configuration Information
facility. The AP bus running in the guest uses
the information returned from this instruction
to configure AP adapters and domains for the
guest machine.
* STFLE.15: Indicates the AP facilities test is available.
The AP bus running in the guest uses the
information.
Signed-off-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 70dd8f1..eeaa7db 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -74,8 +74,10 @@ struct facility_def {
8, /* enhanced-DAT 1 */
9, /* sense-running-status */
10, /* conditional sske */
+ 12, /* AP query configuration */
13, /* ipte-range */
14, /* nonquiescing key-setting */
+ 15, /* AP special-command facility */
73, /* transactional execution */
75, /* access-exception-fetch/store indication */
76, /* msa extension 3 */
--
1.7.1
