Re: [qemu-s390x] [RFC 19/19] s390/facilities: enable AP facilities needed by guest

[Tony Krowiak]

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 <address@hidden> 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 <address@hidden>
> > > > > ---
> > > > >   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?
>