From: Richard Henderson <richard.henderson@linaro.org>
To: LIU Zhiwei <zhiwei_liu@c-sky.com>, laurent@vivier.eu, riku.voipio@iki.fi
Cc: qemu-riscv@nongnu.org,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
wxy194768@alibaba-inc.com, wenmeng_zhang@c-sky.com,
palmer@dabbelt.com, Alistair Francis <Alistair.Francis@wdc.com>
Subject: Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition
Date: Tue, 21 Apr 2020 21:10:00 -0700 [thread overview]
Message-ID: <bf6b46c3-cc39-1b4a-4ae4-9de894721f04@linaro.org> (raw)
In-Reply-To: <f6dc4fa7-fed5-28a1-5922-68e9a0510de5@c-sky.com>
On 4/21/20 7:34 PM, LIU Zhiwei wrote:
> Ping.
>
> When I port RISU, I find this bug. I can't get the correct registers from the
> struct ucontext_t parameter in the signal handler.
The RISC-V Linux ABI will need to be extended to handle RVV state.
There is room in your sigcontext structure:
> struct __riscv_q_ext_state {
> __u64 f[64] __attribute__((aligned(16)));
> __u32 fcsr;
> /*
> * Reserved for expansion of sigcontext structure. Currently zeroed
> * upon signal, and must be zero upon sigreturn.
> */
> __u32 reserved[3];
> };
in uc->uc_mcontext.sc_fpregs.q.
That reserved field is going to have to be used in some way.
My suggestion is to use some sort of extendable record list, akin to AArch64:
struct _aarch64_ctx {
__u32 magic;
__u32 size;
};
One of the 3 zeros could be the total size of the extensions, so that it's easy
to validate the size or memcpy the lot without parsing each individual record.
The other two zeros could be the first header of the next record. Which in
this case also allows the payload of that first record to be aligned mod 16,
which could come in handy.
Talk to the risc-v kernel engineers and come up with a plan that includes room
for the next architecture extension as well. They may have already done so,
but I'm not monitoring the correct mailing list to know.
r~
WARNING: multiple messages have this Message-ID (diff)
From: Richard Henderson <richard.henderson@linaro.org>
To: LIU Zhiwei <zhiwei_liu@c-sky.com>, laurent@vivier.eu, riku.voipio@iki.fi
Cc: Alistair Francis <Alistair.Francis@wdc.com>,
palmer@dabbelt.com, wenmeng_zhang@c-sky.com,
qemu-riscv@nongnu.org, wxy194768@alibaba-inc.com,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition
Date: Tue, 21 Apr 2020 21:10:00 -0700 [thread overview]
Message-ID: <bf6b46c3-cc39-1b4a-4ae4-9de894721f04@linaro.org> (raw)
In-Reply-To: <f6dc4fa7-fed5-28a1-5922-68e9a0510de5@c-sky.com>
On 4/21/20 7:34 PM, LIU Zhiwei wrote:
> Ping.
>
> When I port RISU, I find this bug. I can't get the correct registers from the
> struct ucontext_t parameter in the signal handler.
The RISC-V Linux ABI will need to be extended to handle RVV state.
There is room in your sigcontext structure:
> struct __riscv_q_ext_state {
> __u64 f[64] __attribute__((aligned(16)));
> __u32 fcsr;
> /*
> * Reserved for expansion of sigcontext structure. Currently zeroed
> * upon signal, and must be zero upon sigreturn.
> */
> __u32 reserved[3];
> };
in uc->uc_mcontext.sc_fpregs.q.
That reserved field is going to have to be used in some way.
My suggestion is to use some sort of extendable record list, akin to AArch64:
struct _aarch64_ctx {
__u32 magic;
__u32 size;
};
One of the 3 zeros could be the total size of the extensions, so that it's easy
to validate the size or memcpy the lot without parsing each individual record.
The other two zeros could be the first header of the next record. Which in
this case also allows the payload of that first record to be aligned mod 16,
which could come in handy.
Talk to the risc-v kernel engineers and come up with a plan that includes room
for the next architecture extension as well. They may have already done so,
but I'm not monitoring the correct mailing list to know.
r~
next prev parent reply other threads:[~2020-04-22 4:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 2:08 [PATCH] linux-user/riscv: fix up struct target_ucontext definition LIU Zhiwei
2020-04-12 2:08 ` LIU Zhiwei
2020-04-22 2:34 ` LIU Zhiwei
2020-04-22 2:34 ` LIU Zhiwei
2020-04-22 4:10 ` Richard Henderson [this message]
2020-04-22 4:10 ` Richard Henderson
2020-04-22 18:05 ` Alistair Francis
2020-04-22 18:05 ` Alistair Francis
2020-04-22 19:20 ` Richard Henderson
2020-04-22 19:20 ` Richard Henderson
2020-04-22 21:18 ` Alistair Francis
2020-04-22 21:18 ` Alistair Francis
2020-04-23 1:55 ` LIU Zhiwei
2020-04-23 1:55 ` LIU Zhiwei
2020-04-23 19:45 ` Richard Henderson
2020-04-23 19:45 ` Richard Henderson
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=bf6b46c3-cc39-1b4a-4ae4-9de894721f04@linaro.org \
--to=richard.henderson@linaro.org \
--cc=Alistair.Francis@wdc.com \
--cc=laurent@vivier.eu \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=wenmeng_zhang@c-sky.com \
--cc=wxy194768@alibaba-inc.com \
--cc=zhiwei_liu@c-sky.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.