[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32()
From: |
Peter Maydell |
Subject: |
Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32() |
Date: |
Tue, 13 Dec 2022 16:21:08 +0000 |
On Tue, 13 Dec 2022 at 16:14, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 12/13/22 10:10, Philippe Mathieu-Daudé wrote:
> > On 13/12/22 17:00, Richard Henderson wrote:
> >> On 12/13/22 06:52, Philippe Mathieu-Daudé wrote:
> >>> Assuming the developers of commits 2c50e26efd ("powerpc: Add
> >>> a virtex5 ml507 refdesign board") and 4b387f9ee1 ("ppc: Add
> >>> aCube Sam460ex board") were testing on a little-endian setup,
> >>> they meant to use const_le32() instead of tswap32() here,
> >>> since tswap32() depends on the host endianness.
> >>
> >> tswap depends on target endianness.
> >
> > Yes, it depends on both host/target endianness. What I meant
> > is we shouldn't have system code depending on host endianness.
>
> It compares host vs target endianness, to determine if a swap is needed. But
> the real
> dependency is target endianness.
It does seem odd, though. We have a value in host endianness
(the EPAPR_MAGIC constant, which is host-endian by virtue of
being a C constant). But we're storing it to env->gpr[], which
is to say the CPUPPCState general purpose register array. Isn't
that array *also* kept in host endianness order?
If so, then the right thing here is "don't swap at all",
i.e. just "env->gpr[6] = EPAPR_MAGIC;". But that would imply
that the current code is setting the wrong value for the GPR
on little-endian hosts, which seems a bit unlikely...
thanks
-- PMM
- [RFC PATCH-for-8.0 0/3] hw/ppc: Remove tswap() calls, Philippe Mathieu-Daudé, 2022/12/13
- [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Philippe Mathieu-Daudé, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Richard Henderson, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Philippe Mathieu-Daudé, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Richard Henderson, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(),
Peter Maydell <=
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Richard Henderson, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Cédric Le Goater, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Peter Maydell, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Edgar E. Iglesias, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), BALATON Zoltan, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Peter Maydell, 2022/12/13
- Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32(), Cédric Le Goater, 2022/12/13
[RFC PATCH-for-8.0 2/3] hw/ppc/spapr: Replace tswap64(HPTE) by cpu_to_be64(HPTE), Philippe Mathieu-Daudé, 2022/12/13