Re: kern/55958: pciback.hide parsing error

[Aleksey Arens <aza.sea.agenda%gmail.com@localhost>]

>      I'm pretty sure that somebody previously mentioned that Xen
> requires multiboot.  I've haven't read your entire message, but
> unfortunately it appears that you have spent a lot of time on this
> for naught.  Our native bootloader can do multiboot and has been
> able to boot Xen for many years.  You should have a look here:
> http://wiki.netbsd.org/ports/xen/ and here:
> http://wiki.netbsd.org/ports/xen/howto/ .  This is from my development
> box:
>
> menu=Boot Xen with 6GB for dom0:load /netbsd.xen0 console=pc;multiboot /xen45-kernel/xen.gz dom0_mem=6GB dom0_max_vcpus=1 dom0_vcpus_pin
>

Thank you for joining the discussion.  One of the essential points in
my previous message is that I suspect that there is at least a bug in
the multiboot implementation in /boot.  I'm also concerned about the
fact that the same data-structures are reused in implementing the
binary module layout for the cases when a native module is loaded and
when a multiboot module is loaded.  I hope that these points would
become clear to you if you invest your time and give your full
attention to the entire message.

Finally, the command passed to the module -- in the example that you
had displayed -- is a bit too short.  To see the issue at hand, you'd
need to make it over 80 characters long, and then observe that it does
get truncated once it makes it to Xen.  This was demonstrated in the
first three messages to this PR.

> The "load" part is what does module loading (in this case, the
> NetBSD kernel which is built as a Xen module) and the "multiboot"
> part is what boots the Xen kernel.  Note that since it is my
> development box, I have many different variants of this line.
>

Could we please go into more details thereby?  The Xen expects the
modules to be loaded according to multiboot protocol.  What I'm seeing
is that "load" uses the same BM_TYPE_KMOD for either the case of
native or multiboot module loading scenario.  Furthermore:
  https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#exec_multiboot
  https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#exec_netbsd
are both calling to the same
  https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#module_init
function, in which the short buffer is copied:
  https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#763

So, clearly, both native and multiboot modules are initialized in an
identical fashion.  This must have led to this bug.  I request that
this bug be fixed, and I propose that it be done by separating the
code responsible for module loading in case of multiboot and Xen.