public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Janosch Frank <frankja@linux.ibm.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	thuth@redhat.com
Subject: Re: [PATCH v1 1/4] s390x: saving regs for interrupts
Date: Thu, 14 Nov 2019 16:21:05 +0100	[thread overview]
Message-ID: <6c84ade5-8a42-9c73-abff-47e019fc11bd@linux.ibm.com> (raw)
In-Reply-To: <b88be625-26b1-9780-fde4-000e3065bdaf@redhat.com>


On 2019-11-14 13:11, David Hildenbrand wrote:
> On 14.11.19 12:57, Pierre Morel wrote:
>>
>> On 2019-11-14 11:28, David Hildenbrand wrote:
>>>
>>>> Am 14.11.2019 um 11:11 schrieb Pierre Morel <pmorel@linux.ibm.com>:
>>>>
>>>> 
>>>>> On 2019-11-13 17:12, Janosch Frank wrote:
>>>>>> On 11/13/19 1:23 PM, Pierre Morel wrote:
>>>>>> If we use multiple source of interrupts, for exemple, using SCLP 
>>>>>> console
>>>>>> to print information while using I/O interrupts or during 
>>>>>> exceptions, we
>>>>>> need to have a re-entrant register saving interruption handling.
>>>>>>
>>>>>> Instead of saving at a static place, let's save the base 
>>>>>> registers on
>>>>>> the stack.
>>>>>>
>>>>>> Note that we keep the static register saving that we need for the 
>>>>>> RESET
>>>>>> tests.
>>>>>>
>>>>>> We also care to give the handlers a pointer to the save registers in
>>>>>> case the handler needs it (fixup_pgm_int needs the old psw address).
>>>>> So you're still ignoring the FPRs...
>>>>> I disassembled a test and looked at all stds and it looks like printf
>>>>> and related functions use them. Wouldn't we overwrite test FPRs if
>>>>> printing in a handler?
>>>> If printf uses the FPRs in my opinion we should modify the 
>>>> compilation options for the library.
>>>>
>>>> What is the reason for printf and related functions to use floating 
>>>> point?
>>>>
>>> Register spilling. This can and will be done.
>>
>>
>> Hum, can you please clarify?
>>
>> AFAIK register spilling is for a compiler, to use memory if it has not
>> enough registers.
>
> Not strictly memory. If the compiler needs more GPRS, it can 
> save/restore GPRS to FPRS.
>
> Any function the compiler generates is free to use the FPRS..
>
>>
>> So your answer is for the my first sentence, meaning yes register
>> spilling will be done
>> or
>> do you mean register spilling is the reason why the compiler use FPRs
>> and it must be done so?
>
> Confused by both options :D The compiler might generate code that uses 
> the FPRS although no floating point instructions are in use. That's 
> why we have to enable the AFP control and properly take care of FPRS 
> being used.
>
>
The compiler has the -msoft-float switch to avoid using the floating 
point instructions and registers, so it is our decision.

Saving the FP registers on exceptions is not very efficient, we loose 
time on each interrupt, not sure that we win it back by using FPregs to 
as Regs backup.

Usually a system at low level uses some enter_fpu, leave_fpu routine to 
enter critical sections using FPU instead of losing time on each 
interruptions.

We can think about this, in between I do as you recomand and save the 
FPregs too.

Best regards,

Pierre


-- 
Pierre Morel
IBM Lab Boeblingen


  reply	other threads:[~2019-11-14 15:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 12:23 [PATCH v1 0/4] s390x: Testing the Subchannel I/O Pierre Morel
2019-11-13 12:23 ` [PATCH v1 1/4] s390x: saving regs for interrupts Pierre Morel
2019-11-13 16:12   ` Janosch Frank
2019-11-14 10:11     ` Pierre Morel
2019-11-14 10:28       ` David Hildenbrand
2019-11-14 11:57         ` Pierre Morel
2019-11-14 12:11           ` David Hildenbrand
2019-11-14 15:21             ` Pierre Morel [this message]
2019-11-14 15:25               ` David Hildenbrand
2019-11-14 16:15                 ` Pierre Morel
2019-11-13 12:23 ` [PATCH v1 2/4] s390x: Define the PSW bits Pierre Morel
2019-11-13 16:05   ` Janosch Frank
2019-11-14  8:40     ` Pierre Morel
2019-11-14  8:53       ` Janosch Frank
2019-11-14 15:25         ` Pierre Morel
2019-11-13 12:23 ` [PATCH v1 3/4] s390x:irq: make IRQ handler weak Pierre Morel
2019-11-15  7:12   ` Thomas Huth
2019-11-18  9:04     ` Pierre Morel
2019-11-13 12:23 ` [PATCH v1 4/4] s390x: Testing the Subchannel I/O read Pierre Morel
2019-11-13 13:05   ` Cornelia Huck
2019-11-14 10:11     ` Pierre Morel
2019-11-21 16:02       ` Cornelia Huck
2019-11-22  9:03         ` Pierre Morel
2019-11-22 10:54           ` Cornelia Huck
2019-11-22 12:48             ` Pierre Morel
2019-11-14  9:15   ` Janosch Frank
2019-11-14 16:38     ` Pierre Morel
2019-11-14 16:51       ` Thomas Huth
2019-11-14 17:50         ` Pierre Morel
2019-11-14 17:09       ` Janosch Frank
2019-11-14 17:55         ` Pierre Morel
2019-11-13 12:35 ` [PATCH v1 0/4] s390x: Testing the Subchannel I/O Thomas Huth
2019-11-13 12:43   ` Pierre Morel

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=6c84ade5-8a42-9c73-abff-47e019fc11bd@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=thuth@redhat.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