From: Sven Schnelle <svens@stackframe.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-devel@nongnu.org, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH 2/3] target/hppa: mask offset bits in gva
Date: Thu, 28 Mar 2024 22:03:27 +0100 [thread overview]
Message-ID: <87jzlm1334.fsf@t14.stackframe.org> (raw)
In-Reply-To: <ec050630-a866-4a51-8878-d35844fb66a6@linaro.org> (Richard Henderson's message of "Sun, 24 Mar 2024 08:13:24 -1000")
Richard Henderson <richard.henderson@linaro.org> writes:
> On 3/23/24 22:09, Sven Schnelle wrote:
>> The CPU seems to mask a few bits in the offset when running
>> under HP-UX. ISR/IOR register contents for an address in
>> the processor HPA (0xfffffffffffa0000) on my C8000 and J6750:
>> running on Linux: 000000003fffffff c0000000fffa0500
>> running on HP-UX: 00000000301fffff c0000000fffa0500
>> I haven't found how this is switched (guess some diag in the
>> firmware), but linux + seabios seems to handle that as well,
>> so lets mask out the additional bits.
>> Signed-off-by: Sven Schnelle <svens@stackframe.org>
>> [..]
> [..]
> Though my argument would suggest the mask should be 0xff for the
> 40-bit physical address, which is not what you see at all, so perhaps
> the thing is moot. I am at a loss to explain why or how HP-UX gets a
> 7-bit hole in the ISR result.
>
> On the other hand, there are some not-well-documented shenanigans (aka
> implementation defined behaviour) between Figure H-8 and Figure H-11,
> where the 62-bit absolute address is expanded to a 64-bit logical
> physical address and then compacted to a 40-bit implementation
> physical address.
>
> We've already got hacks in place for this in hppa_abs_to_phys_pa2_w1,
> which just truncates everything down to 40 bits. But that's probably
> not what the processor is really doing.
I looked into this again, and it's caused by Space-ID hashing. HP-UX asks
PDC/Firmware how many bits are used for the hashing. seabios returns
zero, in which case HP-UX uses a default mask of 0xf01fffffffffffff.
By modifying seabios, i can make HP-UX use the appropriate mask, but
switching of SpaceID hashing entirely is impossible. The reason why
the CPU doesn't strip the bits when running linux is that Linux switches
of Space-ID hashing early in the startup code (before mm gets
initialized).
My J6750 Firmware only returns two values: 0 when Space-ID hashing is
off, 0xfe0 when it is enabled. This is hardcoded in the firmware - the
only thing PDC checks is a bit in Debug Register 2, which enables
Space-ID hashing. 0xfe0 matches the 0xf01f... mask used by HP-UX
pretty well.
So if qemu wants to run 64 Bit HP-UX the proper way, i guess it needs
to implement Space-ID hashing.
next prev parent reply other threads:[~2024-03-28 21:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 8:09 [PATCH 0/3] few hppa fixes for 64bit mode Sven Schnelle
2024-03-24 8:09 ` [PATCH 1/3] target/hppa: use gva_offset_mask() everywhere Sven Schnelle
2024-03-24 16:13 ` Helge Deller
2024-03-24 17:20 ` Richard Henderson
2024-03-24 8:09 ` [PATCH 2/3] target/hppa: mask offset bits in gva Sven Schnelle
2024-03-24 16:24 ` Helge Deller
2024-03-24 18:13 ` Richard Henderson
2024-03-24 18:41 ` Sven Schnelle
2024-03-24 23:14 ` Richard Henderson
2024-03-25 6:27 ` Sven Schnelle
2024-03-28 21:03 ` Sven Schnelle [this message]
2024-04-02 6:01 ` Sven Schnelle
2024-04-02 6:08 ` Richard Henderson
2024-04-02 6:29 ` Sven Schnelle
2024-04-02 22:18 ` Helge Deller
2024-03-24 8:09 ` [PATCH 3/3] target/hppa: fix building gva for wide mode Sven Schnelle
2024-03-24 16:28 ` Helge Deller
2024-03-24 17:20 ` Richard Henderson
2024-03-24 21:39 ` Richard Henderson
2024-03-24 23:38 ` 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=87jzlm1334.fsf@t14.stackframe.org \
--to=svens@stackframe.org \
--cc=deller@gmx.de \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).