qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v2 01/20] target/arm: Add commentary for CPUARMState.exclusiv


From: Peter Maydell
Subject: Re: [PATCH v2 01/20] target/arm: Add commentary for CPUARMState.exclusive_high
Date: Tue, 30 May 2023 16:11:09 +0100

On Fri, 26 May 2023 at 15:44, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 5/26/23 02:49, Juan Quintela wrote:
> > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> >> Hi,
> >>
> >> On 26/5/23 01:25, Richard Henderson wrote:
> >>> Document the meaning of exclusive_high in a big-endian context,
> >>> and why we can't change it now.
> >>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> >>> ---
> >>>    target/arm/cpu.h | 7 +++++++
> >>>    1 file changed, 7 insertions(+)
> >>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> >>> index d469a2637b..4e16eab82e 100644
> >>> --- a/target/arm/cpu.h
> >>> +++ b/target/arm/cpu.h
> >>> @@ -677,8 +677,15 @@ typedef struct CPUArchState {
> >>>            uint64_t zcr_el[4];   /* ZCR_EL[1-3] */
> >>>            uint64_t smcr_el[4];  /* SMCR_EL[1-3] */
> >>>        } vfp;
> >>> +
> >>>        uint64_t exclusive_addr;
> >>>        uint64_t exclusive_val;
> >>> +    /*
> >>> +     * Contains the 'val' for the second 64-bit register of LDXP, which 
> >>> comes
> >>> +     * from the higher address, not the high part of a complete 128-bit 
> >>> value.
> >>> +     * This is perhaps confusingly named, but the name is now baked into 
> >>> the
> >>> +     * migration format.
> >>> +     */
> >>>        uint64_t exclusive_high;
> >>
> >> Can't we rename the field if we add the old name to check_fields_match()
> >> in scripts/vmstate-static-checker.py?

> It's not worth any effort to rename.  Just needed documentation.

Yeah; the important point here is "we can't trivially switch
to recording the exclusive value as 'high:low' of a guest
128 bit value" -- it has to remain "value from low address,
value from high address". Really what is baked into the
migration format is that the semantics of the two fields
are from-low-addr and from-high-addr.

If you replace this:

> >>> +     * This is perhaps confusingly named, but the name is now baked into 
> >>> the
> >>> +     * migration format.

with:
 * In some ways it might be more convenient to record the
 * exclusive value as the low and high halves of a 128 bit
 * data value, but the current semantics of these fields are
 * baked into the migration format.

then:

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM



reply via email to

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