All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>, kvm@vger.kernel.org
Cc: linux-s390@vger.kernel.org, frankja@linux.ibm.com,
	david@redhat.com, cohuck@redhat.com
Subject: Re: [kvm-unit-tests PATCH v8 03/12] s390x: saving regs for interrupts
Date: Mon, 8 Jun 2020 17:29:17 +0200	[thread overview]
Message-ID: <dc936814-13b3-c310-f0b1-1bec47c042b2@redhat.com> (raw)
In-Reply-To: <cde77b21-7fbb-bd09-bd3d-f77c5bd2a088@linux.ibm.com>

On 08/06/2020 16.24, Pierre Morel wrote:
> 
> 
> On 2020-06-08 11:05, Thomas Huth wrote:
>> On 08/06/2020 10.12, Pierre Morel wrote:
>>> If we use multiple source of interrupts, for example, using SCLP
>>> console to print information while using I/O interrupts, we need
>>> to have a re-entrant register saving interruption handling.
>>>
>>> Instead of saving at a static memory address, let's save the base
>>> registers, the floating point registers and the floating point
>>> control register on the stack in case of I/O interrupts
>>>
>>> Note that we keep the static register saving to recover from the
>>> RESET tests.
>>>
>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>>> Acked-by: Janosch Frank <frankja@linux.ibm.com>
>>> ---
>>>   s390x/cstart64.S | 41 +++++++++++++++++++++++++++++++++++++++--
>>>   1 file changed, 39 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/s390x/cstart64.S b/s390x/cstart64.S
>>> index b50c42c..a9d8223 100644
>>> --- a/s390x/cstart64.S
>>> +++ b/s390x/cstart64.S
>>> @@ -119,6 +119,43 @@ memsetxc:
>>>       lmg    %r0, %r15, GEN_LC_SW_INT_GRS
>>>       .endm
>>>   +/* Save registers on the stack (r15), so we can have stacked
>>> interrupts. */
>>> +    .macro SAVE_REGS_STACK
>>> +    /* Allocate a stack frame for 15 general registers */
>>> +    slgfi   %r15, 15 * 8
>>> +    /* Store registers r0 to r14 on the stack */
>>> +    stmg    %r0, %r14, 0(%r15)
>>> +    /* Allocate a stack frame for 16 floating point registers */
>>> +    /* The size of a FP register is the size of an double word */
>>> +    slgfi   %r15, 16 * 8
>>> +    /* Save fp register on stack: offset to SP is multiple of reg
>>> number */
>>> +    .irp i, 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>>> +    std    \i, \i * 8(%r15)
>>> +    .endr
>>> +    /* Save fpc, but keep stack aligned on 64bits */
>>> +    slgfi   %r15, 8
>>> +    efpc    %r0
>>> +    stg    %r0, 0(%r15)
>>> +    .endm
>>
>> I wonder whether it would be sufficient to only save the registers here
>> that are "volatile" according to the ELF ABI? ... that would save quite
>> some space on the stack, I think... OTOH, the old code was also saving
>> all registers, so maybe that's something for a separate patch later...
> 
> I don't think so for the general registers
> The "volatile" registers are lost during a C call, so it is the duty of
> the caller to save them before the call, if he wants, and this is
> possible for the programmer or the compiler to arrange that.
> 
> For interruptions, we steal the CPU with all the registers from the
> program without warning, the program has no possibility to save them.
> So we must save all registers for him.

We certainly have to save the registers that are marked as "volatile" in
the ELF ABI, no discussion. But what about the others? If we do not
touch them in the assembler code, and just jump to a C function, the C
function will save them before changing them, and restore the old value
before returning. So when the interrupt is done, the registers should
contain their original values again, shouldn't they?

> For the FP registers, we surely can do something if we establish a usage
> convention on the floating point.
> A few tests need hardware floating point.

According to the ELF ABI, f0 - f7 are volatile, so they must be saved,
but f8 - f15 should be saved by the called function instead, so I think
we don't need to save them here?

Anyway, as I said, that optimization could also be done in a future
patch instead.

 Thomas

  reply	other threads:[~2020-06-08 15:29 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08  8:12 [kvm-unit-tests PATCH v8 00/12] s390x: Testing the Channel Subsystem I/O Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 01/12] s390x: Use PSW bits definitions in cstart Pierre Morel
2020-06-08  8:43   ` Thomas Huth
2020-06-08 14:33     ` Pierre Morel
2020-06-08 14:52       ` Thomas Huth
2020-06-08 15:28         ` Pierre Morel
2020-06-08 15:30           ` Thomas Huth
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 02/12] s390x: Move control register bit definitions and add AFP to them Pierre Morel
2020-06-08  8:45   ` Thomas Huth
2020-06-08 14:25     ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 03/12] s390x: saving regs for interrupts Pierre Morel
2020-06-08  9:05   ` Thomas Huth
2020-06-08 14:24     ` Pierre Morel
2020-06-08 15:29       ` Thomas Huth [this message]
2020-06-08 16:03         ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 04/12] s390x: interrupt registration Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 05/12] s390x: export the clock get_clock_ms() utility Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 06/12] s390x: clock and delays caluculations Pierre Morel
2020-06-08 15:55   ` Thomas Huth
2020-06-08 16:16     ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 07/12] s390x: define function to wait for interrupt Pierre Morel
2020-06-09  5:07   ` Thomas Huth
2020-06-09  7:54     ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 08/12] s390x: retrieve decimal and hexadecimal kernel parameters Pierre Morel
2020-06-09  5:21   ` Thomas Huth
2020-06-09  7:53     ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 09/12] s390x: Library resources for CSS tests Pierre Morel
2020-06-09  7:09   ` Thomas Huth
2020-06-09 15:01     ` Pierre Morel
2020-06-10 14:51       ` Thomas Huth
2020-06-10 15:10         ` Pierre Morel
2020-06-08  8:12 ` [kvm-unit-tests PATCH v8 10/12] s390x: css: stsch, enumeration test Pierre Morel
2020-06-09  7:39   ` Thomas Huth
2020-06-09 12:20     ` Pierre Morel
2020-06-10 15:54       ` Cornelia Huck
2020-06-08  8:13 ` [kvm-unit-tests PATCH v8 11/12] s390x: css: msch, enable test Pierre Morel
2020-06-09  7:47   ` Thomas Huth
2020-06-09  7:56     ` Pierre Morel
2020-06-08  8:13 ` [kvm-unit-tests PATCH v8 12/12] s390x: css: ssch/tsch with sense and interrupt Pierre Morel
2020-06-09  8:15   ` Thomas Huth
2020-06-09 12:02     ` 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=dc936814-13b3-c310-f0b1-1bec47c042b2@redhat.com \
    --to=thuth@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pmorel@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.