[for-4.0,v3,0/4] allow to load initrd below 4G for recent kernel

Message

Li Zhijian Dec. 3, 2018, 2:48 p.m. UTC

Long long ago, linux kernel has supported up to 4G initrd, but it's header
still hard code to allow loading initrd below 2G only.
 cutting from arch/x86/head.S:
 # (Header version 0x0203 or later) the highest safe address for the contents
 # of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
 # avoid possible bootloader bugs.

In order to support more than 2G initrd, qemu must allow loading initrd
above 2G address. Luckly, recent kernel introduced a new field to linux header
named xloadflags:XLF_CAN_BE_LOADED_ABOVE_4G which tells bootload an optional
and safe address to load initrd.

Current QEMU/BIOS always loads initrd below below_4g_mem_size which always
less than 4G, so here limiting initrd_max to 4G - 1 simply is enough if
this bit is set.

Default roms(Seabios + optionrom(linuxboot_dma)) works as expected with this
patchset.

changes:
V3:
 - rebase code basing on http://patchwork.ozlabs.org/cover/1005990 and
   https://patchew.org/QEMU/[e-mail]
 - add new patch 3/4 to import header bootparam.h (Michael S. Tsirkin)

V2: add 2 patches(3/5, 4/5) to fix potential loading issue.

Li Zhijian (4):
  unify len and addr type for memory/address APIs
  refactor load_image_size
  i386: import bootparam.h
  i386: allow to load initrd below 4G for recent linux

 exec.c                    | 47 +++++++++++++++++++++++------------------------
 hw/core/loader.c          | 11 +++++------
 hw/i386/pc.c              | 25 ++++++++++---------------
 include/exec/cpu-all.h    |  2 +-
 include/exec/cpu-common.h |  8 ++++----
 include/exec/memory.h     | 22 +++++++++++-----------
 6 files changed, 54 insertions(+), 61 deletions(-)

Comments

Peter Maydell Dec. 3, 2018, 2:42 p.m. UTC | #1

On Mon, 3 Dec 2018 at 14:39, Li Zhijian <[e-mail]> wrote:
>
> Some address/memory APIs have different type between
> 'hwaddr/target_ulong addr' and 'int len'. It is very unsafety, espcially
> some APIs will be passed a non-int len by caller which might cause
> overflow quietly.
> Below is an potential overflow case:
>     dma_memory_read(uint32_t len)
>       -> dma_memory_rw(uint32_t len)
>         -> dma_memory_rw_relaxed(uint32_t len)
>           -> address_space_rw(int len) # len overflow
>
> CC: Paolo Bonzini <[e-mail]>
> CC: Peter Crosthwaite <[e-mail]>
> CC: Richard Henderson <[e-mail]>
> CC: Peter Maydell <[e-mail]>
> Signed-off-by: Li Zhijian <[e-mail]>
>

Reviewed-by: Peter Maydell <[e-mail]>

thanks
-- PMM