public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	linux-kernel@vger.kernel.org
Cc: linux-s390@vger.kernel.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Subject: Re: [PATCH v1] KVM: s390: store DXC/VXC in fpc on DATA/Vector-processing exceptions
Date: Thu, 23 Aug 2018 19:44:20 +0200	[thread overview]
Message-ID: <b613c011-67f0-317d-c430-cdccfbded46f@redhat.com> (raw)
In-Reply-To: <7c7e52aa-7b07-d146-ac4e-2b1afea6a83d@de.ibm.com>

On 23.08.2018 17:43, Christian Borntraeger wrote:
> 
> 
> On 08/22/2018 11:53 AM, David Hildenbrand wrote:
>> When DATA exceptions and vector-processing exceptions (program interrupts)
>> are injected, the DXC/VXC is also to be stored in the fpc, if AFP is
>> enabled in CR0.
>>
>> This can happen inside KVM when reinjecting an interrupt during program
>> interrupt intercepts. These are triggered for example when debugging the
>> guest (concurrent PER events result in an intercept instead of an
>> injection of such interrupts).
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>
>> Only compile-tested.
> 
> I checked the Linux code (arch/s390/kernel/traps.c) and Linux uses the FPC (and
> not the lowcore field) to decide about the signal (SIGFPE) and si_code. So we want
> to have the correct DXC/VXC value.
> 
> Now, I wrote a short test program that does
> feenableexcept(FE_DIVBYZERO);
> and a division by zero.
> and attached gdb to that guest together with a breakpoint on the divide (and the instruction
> after).
> I get the pint exit for the instruction after (as it is suppressing) and at this point in
> time the guest fpc already contains the correct DXC value. So you patch will certainly not
> hurt, but it seems not necessary.

Thanks for trying. Wonder if that is documented behavior or just works
by pure luck.

E.g. it would be interesting to see what other instructions do that
usually don't touch the DXC, except when injecting an exception. E.g. CRT.

But if you believe this is not needed, we can also drop it. (if ever
somebody would want to inject from QEMU, he could also just set the fpc
directly)

> 
> Still trying to look further if I missed something.
> 
>>
>>  arch/s390/include/asm/ctl_reg.h | 1 +
>>  arch/s390/kvm/interrupt.c       | 8 ++++++++
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/arch/s390/include/asm/ctl_reg.h b/arch/s390/include/asm/ctl_reg.h
>> index 4600453536c2..88f3f14baee9 100644
>> --- a/arch/s390/include/asm/ctl_reg.h
>> +++ b/arch/s390/include/asm/ctl_reg.h
>> @@ -11,6 +11,7 @@
>>  #include <linux/const.h>
>>  
>>  #define CR0_CLOCK_COMPARATOR_SIGN	_BITUL(63 - 10)
>> +#define CR0_AFP_REGISTER_CONTROL	_BITUL(63 - 45)
>>  #define CR0_EMERGENCY_SIGNAL_SUBMASK	_BITUL(63 - 49)
>>  #define CR0_EXTERNAL_CALL_SUBMASK	_BITUL(63 - 50)
>>  #define CR0_CLOCK_COMPARATOR_SUBMASK	_BITUL(63 - 52)
>> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
>> index fcb55b02990e..5b5754d8f460 100644
>> --- a/arch/s390/kvm/interrupt.c
>> +++ b/arch/s390/kvm/interrupt.c
>> @@ -765,6 +765,14 @@ static int __must_check __deliver_prog(struct kvm_vcpu *vcpu)
>>  		break;
>>  	case PGM_VECTOR_PROCESSING:
>>  	case PGM_DATA:
>> +		if (vcpu->arch.sie_block->gcr[0] & CR0_AFP_REGISTER_CONTROL) {
>> +			/* make sure the new fpc will be lazily loaded */
>> +			save_fpu_regs();
>> +			/* the DXC/VXC cannot make the fpc invalid */
>> +			current->thread.fpu.fpc &= ~0xff00u;
>> +			current->thread.fpu.fpc |= (pgm_info.data_exc_code << 8)
>> +						   & 0xff00u;
> 
> maybe reuse  FPC_DXC_MASK instead of 0xff00 ?
> 

Sure, didn't know about that.


-- 

Thanks,

David / dhildenb

  reply	other threads:[~2018-08-23 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22  9:53 [PATCH v1] KVM: s390: store DXC/VXC in fpc on DATA/Vector-processing exceptions David Hildenbrand
2018-08-22 10:31 ` Janosch Frank
2018-08-22 11:13   ` David Hildenbrand
2018-08-23 15:43 ` Christian Borntraeger
2018-08-23 17:44   ` David Hildenbrand [this message]
2018-08-24  6:34     ` Christian Borntraeger
2018-08-24  8:10       ` David Hildenbrand

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=b613c011-67f0-317d-c430-cdccfbded46f@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schwidefsky@de.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox