All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.