Re: [PATCH 2/3] target/hppa: mask offset bits in gva

On 4/2/24 08:29, Sven Schnelle wrote: Richard Henderson writes: On 4/1/24 20:01, Sven Schnelle wrote: Implement dr2 and the mfdiag/mtdiag instructions. dr2 contains a bit which enables/disables space id hashing. Seabios would then set this bit when booting. Linux would disable it again during

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

Richard Henderson writes: > On 4/1/24 20:01, Sven Schnelle wrote: >> Implement dr2 and the mfdiag/mtdiag instructions. dr2 contains a bit >> which enables/disables space id hashing. Seabios would then set >> this bit when booting. Linux would disable it again during boot (this >> would be the sam

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

On 4/1/24 20:01, Sven Schnelle wrote: Implement dr2 and the mfdiag/mtdiag instructions. dr2 contains a bit which enables/disables space id hashing. Seabios would then set this bit when booting. Linux would disable it again during boot (this would be the same like on real hardware), while HP-UX wo

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

Richard, Sven Schnelle writes: > Richard Henderson 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 (0xfffa) on my C8000 and J6750: >

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

Richard Henderson 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 (0xfffa) on my C8000 and J6750: >> running on Linux: 3fff c000

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

Richard Henderson writes: > On 3/24/24 08:41, Sven Schnelle wrote: >> 7f09e0: val=000fffb0301f r2=110e0f01 r1=01fff600 >> phys=fffb 4K aid=1 pl1=0, pl2=0 type=1 (DATA RW) >> 'val' is the value constructed from IOR/ISR, > > Is this byte swapped in some weird way?

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

On 3/24/24 08:41, Sven Schnelle wrote: 7f09e0: val=000fffb0301f r2=110e0f01 r1=01fff600 phys=fffb 4K aid=1 pl1=0, pl2=0 type=1 (DATA RW) 'val' is the value constructed from IOR/ISR, Is this byte swapped in some weird way? I do not see how 'val' corresponds to

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

Hi Richard, Richard Henderson writes: > In particular Figure 2-14 for "data translation disabled" may be > instructive. Suppose the cpu does not implement all of the physical > address lines (true for all extant pa-risc cpus; qemu implements 40 > bits to match pa-8500 iirc). Suppose when repor

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

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 (0xfffa) on my C8000 and J6750: running on Linux: 3fff c000fffa0500 running on HP-UX:

Re: [PATCH 2/3] target/hppa: mask offset bits in gva

On 3/24/24 09: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 (0xfffa) on my C8000 and J6750: running on Linux: 3fff c000fffa0500 running on HP-UX:

[PATCH 2/3] target/hppa: mask offset bits in gva

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 (0xfffa) on my C8000 and J6750: running on Linux: 3fff c000fffa0500 running on HP-UX: 301f c000fffa0500 I haven't foun