Message ID | 1541674784-25936-1-git-send-email-lizhijian@cn.fujitsu.com (mailing list archive) |
---|---|
Headers | show |
Series | support initrd size up to 4G | expand |
Under review, the following patch adds acceptance tests for the initrd option: https://www.mail-archive.com/qemu-devel@nongnu.org/msg567776.html The test should be updated in case this series get merged. Maybe the best would be to include those tests along with this series actually. - Wainer On 11/08/2018 08:59 AM, Li Zhijian wrote: > Long long ago, linux kernel have supported up to 4G initrd, but it's header still > hard code to allow 2G - 1 only. > # (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. > > kexec is one of the known scenario which has supported up to 4G initrd. > > This patches is to enable up to 4G initrd, Seabios + optionrom(linuxboot_dma) > works as expected so far. > > 3/3 has a huge change of address/memory APIs. > I replace 'int len' in a stupid way, but it looks not safety. > $ sed -i 's/int len/uint32_t len/' exec.c > $ make # and check compiling errors > $ sed -i 's/int len/uint32_t len/' cpu-all.h > $ make -i 's/int len/uint32_t len/' include/exec/cpu-common.h > $ make -i 's/int len/uint32_t len/' include/exec/memory.h > $ make # all errors gone > > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Peter Crosthwaite <crosthwaite.peter@gmail.com> > CC: Richard Henderson <rth@twiddle.net> > > Li Zhijian (3): > i386: set initrd_max to 4G - 1 to allow up to 4G initrd > change size type from int to int64_t on load_image() > change int len to uin32_t len > > exec.c | 42 +++++++++++++++++++++--------------------- > hw/core/loader.c | 3 ++- > hw/i386/pc.c | 6 ++++++ > include/exec/cpu-all.h | 2 +- > include/exec/cpu-common.h | 10 +++++----- > include/exec/memory.h | 20 ++++++++++---------- > 6 files changed, 45 insertions(+), 38 deletions(-) >