Add a new option rom for the multiboot loader, using DMA transfers to copy
data instead of "rep insb".
This significantly lowers QEMU's startup latency by a factor of about 40,
for example, going from 30sec to 0.8sec when loading modules of 120MB
in size.
Signed-off-by: Marcus Hähnel <marcus.haehnel@kernkonzept.com>
Signed-off-by: Adam Lackorzynski <adam@l4re.org>
[Modified to keep the non-DMA code depending on #ifdef USE_FW_CFG_DMA;
do not write below stack. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Much of fw_cfg.h's contents is #ifndef NO_QEMU_PROTOS. This lets a
few places include it without satisfying the dependencies of the
suppressed code. If you somehow include it with NO_QEMU_PROTOS, any
future includes are ignored. Unnecessarily unclean.
Move the stuff not under NO_QEMU_PROTOS into its own header
fw_cfg_keys.h, and include it as appropriate. Tidy up the moved code
to please checkpatch.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Even though hw/i386/pc.c tries to compute a valid loading address for the
initrd, close to the top of RAM, this does not take into account other
data that is malloced into that memory by SeaBIOS.
Luckily we can easily look at the memory map to find out how much memory is
used up there. This patch places the initrd in the first four gigabytes,
below the first hole (as returned by INT 15h, AX=e801h).
Without this patch:
[ 0.000000] init_memory_mapping: [mem 0x07000000-0x07fdffff]
[ 0.000000] RAMDISK: [mem 0x0710a000-0x07fd7fff]
With this patch:
[ 0.000000] init_memory_mapping: [mem 0x07000000-0x07fdffff]
[ 0.000000] RAMDISK: [mem 0x07112000-0x07fdffff]
So linuxboot is able to use the 64k that were added as padding for
QEMU <= 2.1.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Always add a byte before the final 512-bytes alignment to reserve the
space for the ROM checksum.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Currently linuxboot.bin and multiboot.bin option roms override int19
vector to intercept boot process. No sane option rom should do that.
Provide bev entry instead that will be called by BIOS if option rom
is selected for booting.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Commit dd4239d657 broke multiboot. It replaced the
instruction "rep insb (%dx), %es:(%edi)" by the binary output of
"addr32 rep insb (%dx), %es:(%di)".
Linuxboot calls the respective helper function in a code16 section. So the
original instruction was automatically translated to its "addr32" equivalent.
For multiboot, we're running in code32 so gcc didn't add the "addr32" which
breaks the instruction.
This patch splits that helper function in one which uses addr32 and one which
does not, so everyone's happy.
The good news is that nobody probably cared so far. The bundled multiboot.bin
binary was built before the change and is thus correct.
Please also put this patch into -stable.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
In the spirit of ff56954baf, fix the
build of linuxboot.S with old as(1) (as found in some BSD base systems)
by emitting the bytes of the insn it doesn't like instead.
Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
We will have a linux boot option rom soon, so let's take all functionality
that might be useful for both to a header file that both roms can include.
That way we only have to write fw_cfg access code once.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
