* [Qemu-devel] [PATCH] Increase max -kernel size
@ 2007-03-27 16:14 Gwenole Beauchesne
2007-03-27 16:32 ` Daniel Jacobowitz
2007-03-27 19:16 ` Thiemo Seufer
0 siblings, 2 replies; 11+ messages in thread
From: Gwenole Beauchesne @ 2007-03-27 16:14 UTC (permalink / raw)
To: qemu-devel
Hi,
The following patch increases max kernel size to 8 MB when qemu is invoked
with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
initrd (e.g. <Cooker>/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
Thanks,
Gwenole.
2007-03-27 Gwenole Beauchesne <gbeauchesne@mandriva.com>
* hw/pc.c (INITRD_LOAD_ADDR): Increase max kernel size with
initrd.
--- qemu-0.9.0/hw/pc.c.increase-initrd-load-addr 2007-03-15 13:36:53.000000000 -0400
+++ qemu-0.9.0/hw/pc.c 2007-03-27 13:27:43.000000000 -0400
@@ -37,7 +37,7 @@ extern int kvm_allowed;
#define LINUX_BOOT_FILENAME "linux_boot.bin"
#define KERNEL_LOAD_ADDR 0x00100000
-#define INITRD_LOAD_ADDR 0x00600000
+#define INITRD_LOAD_ADDR 0x00900000
#define KERNEL_PARAMS_ADDR 0x00090000
#define KERNEL_CMDLINE_ADDR 0x00099000
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 16:14 [Qemu-devel] [PATCH] Increase max -kernel size Gwenole Beauchesne
@ 2007-03-27 16:32 ` Daniel Jacobowitz
2007-03-27 19:16 ` Thiemo Seufer
1 sibling, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-03-27 16:32 UTC (permalink / raw)
To: qemu-devel
On Tue, Mar 27, 2007 at 06:14:22PM +0200, Gwenole Beauchesne wrote:
> Hi,
>
> The following patch increases max kernel size to 8 MB when qemu is invoked
> with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> initrd (e.g. <Cooker>/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
When I talked to Fabrice about this he recommended looking at what
other loaders (lilo, grub) do to avoid overwriting the kernel. I've
been meaning to do that for months but never got around to it.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 16:14 [Qemu-devel] [PATCH] Increase max -kernel size Gwenole Beauchesne
2007-03-27 16:32 ` Daniel Jacobowitz
@ 2007-03-27 19:16 ` Thiemo Seufer
2007-03-27 21:25 ` Daniel Jacobowitz
1 sibling, 1 reply; 11+ messages in thread
From: Thiemo Seufer @ 2007-03-27 19:16 UTC (permalink / raw)
To: Gwenole Beauchesne; +Cc: qemu-devel
Gwenole Beauchesne wrote:
> Hi,
>
> The following patch increases max kernel size to 8 MB when qemu is invoked
> with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> initrd (e.g. <Cooker>/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
I would like a patch which adjusts the initrd load address dynamically,
depending on the kernel load size, instead of hardcoding just a
different magic number.
Thiemo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 19:16 ` Thiemo Seufer
@ 2007-03-27 21:25 ` Daniel Jacobowitz
2007-03-27 21:56 ` Thiemo Seufer
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-03-27 21:25 UTC (permalink / raw)
To: qemu-devel
On Tue, Mar 27, 2007 at 08:16:40PM +0100, Thiemo Seufer wrote:
> Gwenole Beauchesne wrote:
> > Hi,
> >
> > The following patch increases max kernel size to 8 MB when qemu is invoked
> > with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> > initrd (e.g. <Cooker>/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
>
> I would like a patch which adjusts the initrd load address dynamically,
> depending on the kernel load size, instead of hardcoding just a
> different magic number.
Note, that does not readily work - this is where we load the
compressed kernel image and initrd, but what matters is the size it
gets uncompressed to.
I don't remember any more than that so I'm sorry if it's total
garbage, which it might be. I did write a patch to stick the initrd
right after the loaded kernel; it didn't work and I convinced myself
that was the reason.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 21:25 ` Daniel Jacobowitz
@ 2007-03-27 21:56 ` Thiemo Seufer
2007-03-27 22:27 ` Paul Brook
0 siblings, 1 reply; 11+ messages in thread
From: Thiemo Seufer @ 2007-03-27 21:56 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: qemu-devel
Daniel Jacobowitz wrote:
> On Tue, Mar 27, 2007 at 08:16:40PM +0100, Thiemo Seufer wrote:
> > Gwenole Beauchesne wrote:
> > > Hi,
> > >
> > > The following patch increases max kernel size to 8 MB when qemu is invoked
> > > with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> > > initrd (e.g. <Cooker>/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
> >
> > I would like a patch which adjusts the initrd load address dynamically,
> > depending on the kernel load size, instead of hardcoding just a
> > different magic number.
>
> Note, that does not readily work - this is where we load the
> compressed kernel image and initrd, but what matters is the size it
> gets uncompressed to.
I think what matters is the space taken by (uncompressed and loaded)
kernel ALLOC segments. Everything above that should be ok to load a
ramdisk.
IOW, the ELF loader would need to return the topmost address it came
across, including .bss-like parts. The up-aligned value would become
the initrd load address.
Thiemo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 21:56 ` Thiemo Seufer
@ 2007-03-27 22:27 ` Paul Brook
2007-03-27 23:35 ` Thiemo Seufer
0 siblings, 1 reply; 11+ messages in thread
From: Paul Brook @ 2007-03-27 22:27 UTC (permalink / raw)
To: qemu-devel
> > Note, that does not readily work - this is where we load the
> > compressed kernel image and initrd, but what matters is the size it
> > gets uncompressed to.
>
> I think what matters is the space taken by (uncompressed and loaded)
> kernel ALLOC segments. Everything above that should be ok to load a
> ramdisk.
>
> IOW, the ELF loader would need to return the topmost address it came
> across, including .bss-like parts. The up-aligned value would become
> the initrd load address.
That only works if qemu is loading the uncomplressed ELF vmlinux image
directly. In most cases it will be loading a binary blob (or ELF file) of the
compressed zImage. In this case it has no way of telling how big the final
kernel ALLOC sections are.
By my reading grub puts the inirtd at 0x38000000 (896Mb), or at the top of
physical memory, whichever is lowest, and lilo puts it at the top of physical
memory, give or take a bit of alignment.
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 22:27 ` Paul Brook
@ 2007-03-27 23:35 ` Thiemo Seufer
2007-03-28 2:21 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Thiemo Seufer @ 2007-03-27 23:35 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
Paul Brook wrote:
> > > Note, that does not readily work - this is where we load the
> > > compressed kernel image and initrd, but what matters is the size it
> > > gets uncompressed to.
> >
> > I think what matters is the space taken by (uncompressed and loaded)
> > kernel ALLOC segments. Everything above that should be ok to load a
> > ramdisk.
> >
> > IOW, the ELF loader would need to return the topmost address it came
> > across, including .bss-like parts. The up-aligned value would become
> > the initrd load address.
>
> That only works if qemu is loading the uncomplressed ELF vmlinux image
> directly. In most cases it will be loading a binary blob (or ELF file) of the
> compressed zImage. In this case it has no way of telling how big the final
> kernel ALLOC sections are.
Right, a piggyback-style loader would likely fail in that case.
Thiemo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-27 23:35 ` Thiemo Seufer
@ 2007-03-28 2:21 ` Daniel Jacobowitz
2007-03-28 14:00 ` Paul Brook
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-03-28 2:21 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Paul Brook, qemu-devel
On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote:
> Right, a piggyback-style loader would likely fail in that case.
Which is exactly the interesting case for x86_64. So, since Paul's
verified that grub and lilo just put them far apart, maybe bumping up
the size is the right thing to do. Or always putting the initrd at
the top of emulated RAM.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-28 2:21 ` Daniel Jacobowitz
@ 2007-03-28 14:00 ` Paul Brook
2007-03-31 15:41 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Paul Brook @ 2007-03-28 14:00 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: qemu-devel
On Wednesday 28 March 2007 03:21, Daniel Jacobowitz wrote:
> On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote:
> > Right, a piggyback-style loader would likely fail in that case.
>
> Which is exactly the interesting case for x86_64. So, since Paul's
> verified that grub and lilo just put them far apart, maybe bumping up
> the size is the right thing to do. Or always putting the initrd at
> the top of emulated RAM.
I'd prefer the latter, so that both big and small machines work. Linux still
(just about) boots on 8Mb machines.
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-28 14:00 ` Paul Brook
@ 2007-03-31 15:41 ` Daniel Jacobowitz
2007-03-31 16:50 ` Paul Brook
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-03-31 15:41 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
On Wed, Mar 28, 2007 at 03:00:08PM +0100, Paul Brook wrote:
> On Wednesday 28 March 2007 03:21, Daniel Jacobowitz wrote:
> > On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote:
> > > Right, a piggyback-style loader would likely fail in that case.
> >
> > Which is exactly the interesting case for x86_64. So, since Paul's
> > verified that grub and lilo just put them far apart, maybe bumping up
> > the size is the right thing to do. Or always putting the initrd at
> > the top of emulated RAM.
>
> I'd prefer the latter, so that both big and small machines work. Linux still
> (just about) boots on 8Mb machines.
Like this? I can't reliably test that it fixes the problem - for some
bizarre reason, I can now load kernels without this patch. But it
looks right and I can load kernels with it, too.
--
Daniel Jacobowitz
CodeSourcery
---
hw/pc.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
Index: qemu/hw/pc.c
===================================================================
--- qemu.orig/hw/pc.c 2007-03-31 11:36:34.000000000 -0400
+++ qemu/hw/pc.c 2007-03-31 11:38:24.000000000 -0400
@@ -32,7 +32,6 @@
#define LINUX_BOOT_FILENAME "linux_boot.bin"
#define KERNEL_LOAD_ADDR 0x00100000
-#define INITRD_LOAD_ADDR 0x00600000
#define KERNEL_PARAMS_ADDR 0x00090000
#define KERNEL_CMDLINE_ADDR 0x00099000
@@ -452,6 +451,7 @@ static void pc_init1(int ram_size, int v
char buf[1024];
int ret, linux_boot, initrd_size, i;
ram_addr_t ram_addr, vga_ram_addr, bios_offset, vga_bios_offset;
+ ram_addr_t initrd_offset;
int bios_size, isa_bios_size, vga_bios_size;
PCIBus *pci_bus;
int piix3_devfn = -1;
@@ -599,8 +599,21 @@ static void pc_init1(int ram_size, int v
/* load initrd */
initrd_size = 0;
+ initrd_offset = 0;
if (initrd_filename) {
- initrd_size = load_image(initrd_filename, phys_ram_base + INITRD_LOAD_ADDR);
+ initrd_size = get_image_size (initrd_filename);
+ if (initrd_size > 0) {
+ initrd_offset = ram_size - initrd_size;
+ if (initrd_size > ram_size ||
+ initrd_offset < KERNEL_LOAD_ADDR + ret) {
+ fprintf(stderr,
+ "qemu: memory too small for initial ram disk '%s'\n",
+ initrd_filename);
+ exit(1);
+ }
+ initrd_size = load_image(initrd_filename,
+ phys_ram_base + initrd_offset);
+ }
if (initrd_size < 0) {
fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
initrd_filename);
@@ -608,7 +621,7 @@ static void pc_init1(int ram_size, int v
}
}
if (initrd_size > 0) {
- stl_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x218, INITRD_LOAD_ADDR);
+ stl_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x218, initrd_offset);
stl_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x21c, initrd_size);
}
pstrcpy(phys_ram_base + KERNEL_CMDLINE_ADDR, 4096,
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [PATCH] Increase max -kernel size
2007-03-31 15:41 ` Daniel Jacobowitz
@ 2007-03-31 16:50 ` Paul Brook
0 siblings, 0 replies; 11+ messages in thread
From: Paul Brook @ 2007-03-31 16:50 UTC (permalink / raw)
To: qemu-devel
> Like this? I can't reliably test that it fixes the problem - for some
> bizarre reason, I can now load kernels without this patch. But it
> looks right and I can load kernels with it, too.
Turns out there's a problem. qemu puts ACPI tables at the top of ram. We have
to be careful to avoid stomping on them.
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-03-31 16:53 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-27 16:14 [Qemu-devel] [PATCH] Increase max -kernel size Gwenole Beauchesne
2007-03-27 16:32 ` Daniel Jacobowitz
2007-03-27 19:16 ` Thiemo Seufer
2007-03-27 21:25 ` Daniel Jacobowitz
2007-03-27 21:56 ` Thiemo Seufer
2007-03-27 22:27 ` Paul Brook
2007-03-27 23:35 ` Thiemo Seufer
2007-03-28 2:21 ` Daniel Jacobowitz
2007-03-28 14:00 ` Paul Brook
2007-03-31 15:41 ` Daniel Jacobowitz
2007-03-31 16:50 ` Paul Brook
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.