Re: [PATCH 3/4] parisc: Use absolute_pointer for memcmp on fixed memory location

From: Guenter Roeck
Date: Sun Sep 12 2021 - 16:29:06 EST

On 9/12/21 12:58 PM, Helge Deller wrote:
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
On Sun, Sep 12, 2021 at 9:02 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:

- running_on_qemu = (memcmp(&PAGE0->pad0, "SeaBIOS", 8) == 0);
+ running_on_qemu = (memcmp(absolute_pointer(&PAGE0->pad0), "SeaBIOS", 8) == 0);

This seems entirely the wrong thing to do, and makes no sense. That
"&PAGE0->pad0" is a perfectly valid pointer, and that's not where the
problem is.

The problem is "PAGE0" itself:

#define PAGE0 ((struct zeropage *)__PAGE_OFFSET)

which takes that absolute offset and creates a pointer out of it.

IOW, _that_ is what should have the "absolute_pointer()" thing, and in
that context the name of that macro and its use actually makes sense.


An alternative - and possibly cleaner - approach that doesn't need
absolute_pointer() at all might be to just do

extern struct zeropage PAGE0;

and then make that PAGE0 be defined to __PAGE_OFFSET in the parisc file.

Then doing things like

running_on_qemu = !memcmp(&PAGE0.pad0, "SeaBIOS", 8);

would JustWork(tm).

Yes, this second approach seems to work nicely, although the patch
then gets slightly bigger.
Below is a tested patch.
I'll check it some further and apply it to the parisc tree then.

There are several PAGE0-> references left in the code after applying your patch.

$ git grep "PAGE0->"
arch/parisc/kernel/firmware.c: if (!PAGE0->mem_kbd.iodc_io)
arch/parisc/kernel/firmware.c: real32_call(PAGE0->mem_kbd.iodc_io,
arch/parisc/kernel/firmware.c: (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
arch/parisc/kernel/firmware.c: PAGE0->, __pa(PAGE0->mem_kbd.dp.layers),
arch/parisc/kernel/smp.c: WARN_ON(((unsigned long)(PAGE0->mem_pdc_hi) << 32
arch/parisc/kernel/smp.c: | PAGE0->mem_pdc) != pdce_proc);

After fixing those, I can build a parisc image and boot it in qemu (32 bit).