| Message ID | 1547197071-14504-5-git-send-email-lizhijian@cn.fujitsu.com |
|---|---|
| State | New |
| Headers | show |
| Series | allow to load initrd below 4G for recent kernel | expand |
On Fri, Jan 11, 2019 at 04:57:51PM +0800, Li Zhijian wrote: > Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)") > linux has supported initrd up to 4 GB, but the header field > ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs". > > When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM, > the firmware(it could be linuxboot_dma.bin) helps to read initrd > contents into guest memory(below ramdisk_max) and jump to kernel. > that's similar with what bootloader does, like grub. > > In addition, initrd_max is uint32_t simply because QEMU doesn't support > the 64-bit boot protocol (specifically the ext_ramdisk_image field). > > Therefore here just limit initrd_max to UINT32_MAX simply as well to > allow initrd to be loaded below 4 GB. > > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Eduardo Habkost <ehabkost@redhat.com> > CC: "Michael S. Tsirkin" <mst@redhat.com> > CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> > Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> > > --- > V5: udpate comments and changelog > V3: correct grammar and check XLF_CAN_BE_LOADED_ABOVE_4G first (Michael S. Tsirkin) > > Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> > --- > hw/i386/pc.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 89c25b2..ea7a3c7 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -904,7 +904,29 @@ static void load_linux(PCMachineState *pcms, > #endif > > /* highest address for loading the initrd */ > - if (protocol >= 0x203) { > + if (protocol >= 0x20c && > + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { > + /* > + * Linux has supported initrd up to 4 GB for a very long time (2007, > + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), > + * though it only sets initrd_max to 2 GB to "work around bootloader > + * bugs". Luckily, QEMU firmware(which does something like bootloader) > + * has supported this. > + * > + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can > + * be loaded into any address. > + * > + * In addition, initrd_max is uint32_t simply because QEMU doesn't > + * support the 64-bit boot protocol (specifically the ext_ramdisk_image > + * field). > + * > + * Therefore here just limit initrd_max to UINT32_MAX simply as well. > + * > + * FIXME: it's possible that linux protocol within [0x208, 0x20c] > + * supports up to 4G initrd as well. I don't understand what exactly this FIXME comment is documenting. What exactly needs to be fixed? > + */ > + initrd_max = UINT32_MAX; > + } else if (protocol >= 0x203) { > initrd_max = ldl_p(header+0x22c); > } else { > initrd_max = 0x37ffffff; > -- > 2.7.4 >
Hi Eduardo On 1/15/19 01:53, Eduardo Habkost wrote: >> + if (protocol >= 0x20c && >> + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { >> + /* >> + * Linux has supported initrd up to 4 GB for a very long time (2007, >> + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), >> + * though it only sets initrd_max to 2 GB to "work around bootloader >> + * bugs". Luckily, QEMU firmware(which does something like bootloader) >> + * has supported this. >> + * >> + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can >> + * be loaded into any address. >> + * >> + * In addition, initrd_max is uint32_t simply because QEMU doesn't >> + * support the 64-bit boot protocol (specifically the ext_ramdisk_image >> + * field). >> + * >> + * Therefore here just limit initrd_max to UINT32_MAX simply as well. >> + * >> + * FIXME: it's possible that linux protocol within [0x208, 0x20c] >> + * supports up to 4G initrd as well. > I don't understand what exactly this FIXME comment is > documenting. What exactly needs to be fixed? > XLF_CAN_BE_LOADED_ABOVE_4G is one of the indicators, actually as comments said, linux has supported up to 4 GB initrd since linux-2.26(protocol version 0x208). I just want to comment that linux with protocol within [0x208, 0x20c] supports up to 4 GB initrd as well. Is documenting with FIXME appropriate? Thanks
On Tue, Jan 15, 2019 at 09:35:09AM +0800, Li Zhijian wrote: > Hi Eduardo > > > On 1/15/19 01:53, Eduardo Habkost wrote: > > + if (protocol >= 0x20c && > + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { > + /* > + * Linux has supported initrd up to 4 GB for a very long time (2007, > + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), > + * though it only sets initrd_max to 2 GB to "work around bootloader > + * bugs". Luckily, QEMU firmware(which does something like bootloader) > + * has supported this. > + * > + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can > + * be loaded into any address. > + * > + * In addition, initrd_max is uint32_t simply because QEMU doesn't > + * support the 64-bit boot protocol (specifically the ext_ramdisk_image > + * field). > + * > + * Therefore here just limit initrd_max to UINT32_MAX simply as well. > + * > + * FIXME: it's possible that linux protocol within [0x208, 0x20c] > + * supports up to 4G initrd as well. > > I don't understand what exactly this FIXME comment is > documenting. What exactly needs to be fixed? > > > XLF_CAN_BE_LOADED_ABOVE_4G is one of the indicators, actually as comments said, > linux has supported up to 4 GB initrd since linux-2.26(protocol version 0x208). > > > I just want to comment that linux with protocol within [0x208, 0x20c] supports up to 4 GB initrd as well. > > Is documenting with FIXME appropriate? > > > Thanks > > Fixme should say what is missing in the qemu implementation. E.g. /* * Bar 2010 and up can actually be supported using foo. * FIXME: make use of foo to support bar. */
Hi Michael, Eduardo On 1/15/19 09:46, Michael S. Tsirkin wrote: > On Tue, Jan 15, 2019 at 09:35:09AM +0800, Li Zhijian wrote: >> Hi Eduardo >> >> >> On 1/15/19 01:53, Eduardo Habkost wrote: >> >> + if (protocol >= 0x20c && >> + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { >> + /* >> + * Linux has supported initrd up to 4 GB for a very long time (2007, >> + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), >> + * though it only sets initrd_max to 2 GB to "work around bootloader >> + * bugs". Luckily, QEMU firmware(which does something like bootloader) >> + * has supported this. >> + * >> + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can >> + * be loaded into any address. >> + * >> + * In addition, initrd_max is uint32_t simply because QEMU doesn't >> + * support the 64-bit boot protocol (specifically the ext_ramdisk_image >> + * field). >> + * >> + * Therefore here just limit initrd_max to UINT32_MAX simply as well. >> + * >> + * FIXME: it's possible that linux protocol within [0x208, 0x20c] >> + * supports up to 4G initrd as well. >> >> I don't understand what exactly this FIXME comment is >> documenting. What exactly needs to be fixed? >> >> >> XLF_CAN_BE_LOADED_ABOVE_4G is one of the indicators, actually as comments said, >> linux has supported up to 4 GB initrd since linux-2.26(protocol version 0x208). >> >> >> I just want to comment that linux with protocol within [0x208, 0x20c] supports up to 4 GB initrd as well. >> >> Is documenting with FIXME appropriate? >> >> >> Thanks >> >> > > Fixme should say what is missing in the qemu implementation. thanks for your explanation @Michael I'd like to update "FIXME" to "NOTE" and move it into git-commit-log if no objection and it's okay to delete it simply if it confuses others :) BTW: any other comments for the others Thanks Zhijian > E.g. > > /* > * Bar 2010 and up can actually be supported using foo. > * FIXME: make use of foo to support bar. > */ > >
diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 89c25b2..ea7a3c7 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -904,7 +904,29 @@ static void load_linux(PCMachineState *pcms, #endif /* highest address for loading the initrd */ - if (protocol >= 0x203) { + if (protocol >= 0x20c && + lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) { + /* + * Linux has supported initrd up to 4 GB for a very long time (2007, + * long before XLF_CAN_BE_LOADED_ABOVE_4G which was added in 2013), + * though it only sets initrd_max to 2 GB to "work around bootloader + * bugs". Luckily, QEMU firmware(which does something like bootloader) + * has supported this. + * + * It's believed that if XLF_CAN_BE_LOADED_ABOVE_4G is set, initrd can + * be loaded into any address. + * + * In addition, initrd_max is uint32_t simply because QEMU doesn't + * support the 64-bit boot protocol (specifically the ext_ramdisk_image + * field). + * + * Therefore here just limit initrd_max to UINT32_MAX simply as well. + * + * FIXME: it's possible that linux protocol within [0x208, 0x20c] + * supports up to 4G initrd as well. + */ + initrd_max = UINT32_MAX; + } else if (protocol >= 0x203) { initrd_max = ldl_p(header+0x22c); } else { initrd_max = 0x37ffffff;
Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)") linux has supported initrd up to 4 GB, but the header field ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs". When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM, the firmware(it could be linuxboot_dma.bin) helps to read initrd contents into guest memory(below ramdisk_max) and jump to kernel. that's similar with what bootloader does, like grub. In addition, initrd_max is uint32_t simply because QEMU doesn't support the 64-bit boot protocol (specifically the ext_ramdisk_image field). Therefore here just limit initrd_max to UINT32_MAX simply as well to allow initrd to be loaded below 4 GB. CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> CC: "Michael S. Tsirkin" <mst@redhat.com> CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> --- V5: udpate comments and changelog V3: correct grammar and check XLF_CAN_BE_LOADED_ABOVE_4G first (Michael S. Tsirkin) Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> --- hw/i386/pc.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)