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.
No?
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
vmlinux.lds.S 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->mem_kbd.spa, __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).
Guenter
