qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition


From: Alistair Francis
Subject: Re: [PATCH] linux-user/riscv: fix up struct target_ucontext definition
Date: Wed, 22 Apr 2020 11:05:05 -0700

On Tue, Apr 21, 2020 at 9:10 PM Richard Henderson
<address@hidden> wrote:
>
> 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.

Just to clarify, this patch is still correct right?

It looks good to me.

Alistair

>
> 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~
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]