qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.


  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).