All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Collin Walling <walling@linux.ibm.com>,
	pbonzini@redhat.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	borntraeger@de.ibm.com, frankja@linux.ibm.com
Subject: Re: [PATCH v3 1/2] s390/setup: diag318: remove bit check and refactor struct
Date: Wed, 3 Apr 2019 14:33:33 +0200	[thread overview]
Message-ID: <20190403143333.2a3db681.cohuck@redhat.com> (raw)
In-Reply-To: <599addd3-a4f8-d4e7-5898-dc45f52cd7a6@redhat.com>

On Wed, 3 Apr 2019 14:03:21 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 02.04.19 19:46, Collin Walling wrote:
> > Execution of DIAGNOSE 0x318 is fenced by checking an SCLP bit
> > for the availability of hardware support for the instruction.
> > 
> > In order to support this instruction for a KVM/QEMU guest, we
> > would need to provide modifications to the SCLP Read SCP Info
> > data, which will in turn reduce the maximum number of CPUs that
> > may be provided to the guest. This issue introduces compatability
> > and legacy concerns.
> > 
> > Let's circumvent this issue by removing the bit check and blindly
> > executing the instruction. An exception table rule is in place to
> > catch the case where hardware does not support this instruction.
> > 
> > While we're at it, let's condense the version code fields in the
> > diag318_info struct until we can determine how it will be used.
> > 
> > This modifies commit 4ad78b8651aacf26b3ab6d1e784952eb70469c43
> > 
> > Signed-off-by: Collin Walling <walling@linux.ibm.com>
> > ---
> >  arch/s390/include/asm/diag.h |  6 ++----
> >  arch/s390/kernel/setup.c     | 12 ++++++------
> >  2 files changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/s390/include/asm/diag.h b/arch/s390/include/asm/diag.h
> > index 19562be22b7e..215516284175 100644
> > --- a/arch/s390/include/asm/diag.h
> > +++ b/arch/s390/include/asm/diag.h
> > @@ -298,10 +298,8 @@ struct diag26c_mac_resp {
> >  union diag318_info {
> >  	unsigned long val;
> >  	struct {
> > -		unsigned int cpnc : 8;
> > -		unsigned int cpvc_linux : 24;
> > -		unsigned char cpvc_distro[3];
> > -		unsigned char zero;
> > +		unsigned long cpnc : 8;
> > +		unsigned long cpvc : 56;

That part looks reasonable (we don't have a proper convention yet, have
we?)

> >  	};
> >  };
> >  
> > diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> > index 2c642af526ce..fe70201f8b5d 100644
> > --- a/arch/s390/kernel/setup.c
> > +++ b/arch/s390/kernel/setup.c
> > @@ -1011,15 +1011,15 @@ static void __init setup_control_program_code(void)
> >  {
> >  	union diag318_info diag318_info = {
> >  		.cpnc = CPNC_LINUX,
> > -		.cpvc_linux = 0,
> > -		.cpvc_distro = {0},
> > +		.cpvc = 0,
> >  	};
> >  
> > -	if (!sclp.has_diag318)
> > -		return;
> > -
> >  	diag_stat_inc(DIAG_STAT_X318);
> > -	asm volatile("diag %0,0,0x318\n" : : "d" (diag318_info.val));
> > +	asm volatile(
> > +		"	diag	%0,0,0x318\n"
> > +		"0:	nopr	%%r7\n"
> > +		EX_TABLE(0b,0b)
> > +		: : "d" (diag318_info.val));
> >  }
> >  
> >  /*
> >   
> 
> That smells like a nasty hack to not expose new features in QEMU and
> deal with the issue of handling CPU limits. No, I don't like this.
> 
> Fix QEMU, not the kernel.
> 

I agree. The compat handling is a bit annoying, but I don't think we
can get around it.

  reply	other threads:[~2019-04-03 12:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 17:46 [PATCH v3 0/2] Use DIAG318 to set Control Program Name & Version Codes Collin Walling
2019-04-02 17:46 ` [PATCH v3 1/2] s390/setup: diag318: remove bit check and refactor struct Collin Walling
2019-04-03  6:36   ` Janosch Frank
2019-04-03 11:28   ` Christian Borntraeger
2019-04-03 12:09     ` David Hildenbrand
2019-04-03 12:10       ` Christian Borntraeger
2019-04-03 12:03   ` David Hildenbrand
2019-04-03 12:33     ` Cornelia Huck [this message]
2019-04-03 14:22       ` Collin Walling
2019-04-02 17:46 ` [PATCH v3 2/2] s390/kvm: diagnose 318 handling Collin Walling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190403143333.2a3db681.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=walling@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.