All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong
@ 2015-11-01 19:02 Tristan Parisot
  2015-11-01 19:03 ` [Qemu-devel] [Bug 1512134] " Tristan Parisot
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Tristan Parisot @ 2015-11-01 19:02 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

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

** Affects: qemu
     Importance: Undecided
         Status: New


** Tags: multiboot

-- 
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong
  2015-11-01 19:02 [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong Tristan Parisot
@ 2015-11-01 19:03 ` Tristan Parisot
  2015-11-02 16:42 ` Max Reitz
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Tristan Parisot @ 2015-11-01 19:03 UTC (permalink / raw)
  To: qemu-devel

I forgot to tell how i detected the issue:
I print all the fields, and in "type", i had the size of  the next entry (and in size, i have always zero, which corresponds to the high part of addr)

-- 
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong
  2015-11-01 19:02 [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong Tristan Parisot
  2015-11-01 19:03 ` [Qemu-devel] [Bug 1512134] " Tristan Parisot
@ 2015-11-02 16:42 ` Max Reitz
  2015-11-08 11:56 ` Tristan Parisot
  2015-11-09 16:59 ` Max Reitz
  3 siblings, 0 replies; 5+ messages in thread
From: Max Reitz @ 2015-11-02 16:42 UTC (permalink / raw)
  To: qemu-devel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong
  2015-11-01 19:02 [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong Tristan Parisot
  2015-11-01 19:03 ` [Qemu-devel] [Bug 1512134] " Tristan Parisot
  2015-11-02 16:42 ` Max Reitz
@ 2015-11-08 11:56 ` Tristan Parisot
  2015-11-09 16:59 ` Max Reitz
  3 siblings, 0 replies; 5+ messages in thread
From: Tristan Parisot @ 2015-11-08 11:56 UTC (permalink / raw)
  To: qemu-devel

Tested today with GRUB 2.0. Indeed, mmap_entry points to the start of
the structure, without a fancy offset. I guess we can close this ticket

-- 
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1512134] Re: Multiboot v1 memory map offset wrong
  2015-11-01 19:02 [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong Tristan Parisot
                   ` (2 preceding siblings ...)
  2015-11-08 11:56 ` Tristan Parisot
@ 2015-11-09 16:59 ` Max Reitz
  3 siblings, 0 replies; 5+ messages in thread
From: Max Reitz @ 2015-11-09 16:59 UTC (permalink / raw)
  To: qemu-devel

** Changed in: qemu
       Status: New => Invalid

-- 
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:
  Invalid

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-11-09 17:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-01 19:02 [Qemu-devel] [Bug 1512134] [NEW] Multiboot v1 memory map offset wrong Tristan Parisot
2015-11-01 19:03 ` [Qemu-devel] [Bug 1512134] " Tristan Parisot
2015-11-02 16:42 ` Max Reitz
2015-11-08 11:56 ` Tristan Parisot
2015-11-09 16:59 ` Max Reitz

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.