All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@linux.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-ppc@nongnu.org
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>,
	Daniel Henrique Barboza <danielhb413@gmail.com>
Subject: Re: [PATCH qemu] spapr: Use address from elf parser for kernel address
Date: Wed, 04 May 2022 16:16:30 -0300	[thread overview]
Message-ID: <87fslp9khd.fsf@linux.ibm.com> (raw)
In-Reply-To: <20220504065536.3534488-1-aik@ozlabs.ru>

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> tl;dr: This allows Big Endian zImage booting via -kernel + x-vof=on.
>
> QEMU loads the kernel at 0x400000 by default which works most of
> the time as Linux kernels are relocatable, 64bit and compiled with "-pie"
> (position independent code). This works for a little endian zImage too.
>
> However a big endian zImage is compiled without -pie, is 32bit, linked to
> 0x4000000 so current QEMU ends up loading it at
> 0x4400000 but keeps spapr->kernel_addr unchanged so booting fails.
>
> This uses the kernel address returned from load_elf().
> If the default kernel_addr is used, there is no change in behavior (as
> translate_kernel_address() takes care of this), which is:
> LE/BE vmlinux and LE zImage boot, BE zImage does not.
> If the VM created with "-machine kernel-addr=0,x-vof=on", then QEMU
> prints a warning and BE zImage boots.

I think we can fix this without needing a different command line for BE
zImage (apart from x-vof, which is a separate matter).

If you look at translate_kernel_address, it cannot really work when the
ELF PhysAddr is != 0. We would always hit this sort of 0x4400000 issue,
so if we fix that function like this...

static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
{
    SpaprMachineState *spapr = opaque;

    return addr ? addr : spapr->kernel_addr;
}

...then we could always use the ELF PhysAddr if it is different from 0
and only use the default load addr if the ELF PhysAddr is 0. If the user
gives kernel_addr on the cmdline, we honor that, even if puts the kernel
over the firmware (we have code to detect that).

> @@ -2988,6 +2990,12 @@ static void spapr_machine_init(MachineState *machine)
>              exit(1);
>          }
>  
> +        if (spapr->kernel_addr != loaded_addr) {

This could be:

        if (spapr->kernel_addr == KERNEL_LOAD_ADDR &&
	    spapr->kernel_addr != loaded_addr) {

So the precedence would be:

1- ELF PhysAddr, if != 0. After all, that is what it's for. BE zImage
   falls here;
    
2- KERNEL_LOAD_ADDR. Via translate_kernel_address, LE/BE vmlinux fall
   here;

3- kernel_addr. The user is probably hacking something, just use what
   they gave us. QEMU will yell if they load the kernel over the fw.

> +            warn_report("spapr: kernel_addr changed from 0x%lx to 0x%lx",
> +                        spapr->kernel_addr, loaded_addr);
> +            spapr->kernel_addr = loaded_addr;
> +        }
> +
>          /* load initrd */
>          if (initrd_filename) {
>              /* Try to locate the initrd in the gap between the kernel


  reply	other threads:[~2022-05-04 19:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  6:55 [PATCH qemu] spapr: Use address from elf parser for kernel address Alexey Kardashevskiy
2022-05-04 19:16 ` Fabiano Rosas [this message]
2022-05-05  3:29   ` Alexey Kardashevskiy
2022-05-05  4:16     ` Joel Stanley
2022-05-05  5:07       ` Alexey Kardashevskiy
2022-05-05 15:50     ` Fabiano Rosas
2022-05-06  4:49       ` Alexey Kardashevskiy
2022-05-11 17:47         ` Fabiano Rosas
2022-05-12 17:47 ` Daniel Henrique Barboza
2022-05-17 18:58 ` Daniel Henrique Barboza
2022-05-18  2:51   ` Alexey Kardashevskiy
2022-05-18 10:07     ` Daniel Henrique Barboza

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=87fslp9khd.fsf@linux.ibm.com \
    --to=farosas@linux.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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.