[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong
From: |
Max Reitz |
Subject: |
[Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong |
Date: |
Mon, 02 Nov 2015 16:42:08 -0000 |
Hi,
Have you tested your code with GRUB (Legacy) itself? Looking at code
from one of my own hobby kernels, and from a hobby kernel that has
largely not been written by me, both are interpreting the fields as qemu
is (i.e. mmap_addr points to a multiboot_mmap_entry, and not to
multiboot_mmap_entry + 4), and I know both to work just fine with GRUB.
I considered the -4 offset to signify that the size field simply does
not count itself, i.e. the size of one multiboot_mmap_entry is $size +
4.
Max
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1512134
Title:
Multiboot v1 memory map offset wrong
Status in QEMU:
New
Bug description:
I'm developping a multiboot kernel for multiboot v1
My multiboot header contains the V1 magic (0x1BADB002) and the flags
0x00010243 (with enabled memory detection, and boot loader name)
When booted in multiboot,
Qemu gives me two pointers:
unsigned long mmap_length;
unsigned long mmap_addr;
mmap_addr shall points to this structure:
struct multiboot_mmap_entry
{
multiboot_uint32_t size;
multiboot_uint64_t addr;
multiboot_uint64_t len;
multiboot_uint32_t type;
}
According to the multiboot v1 specification, mmap_addr should not point to
the start of this structure, but instead, should point to the "addr "field.
Work-arround:
Detect if qemu is used using bootloader_name field.
If it is, do NOT apply a -4 offset to mmap_addr
http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1512134/+subscriptions