NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/55958: pciback.hide parsing error

The following reply was made to PR kern/55958; it has been noted by GNATS.

From: Aleksey Arens <>
Subject: Re: kern/55958: pciback.hide parsing error
Date: Thu, 28 Jan 2021 22:33:46 -0800

 >      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:
 > and here:
 > .  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:
 are both calling to the same
 function, in which the short buffer is copied:
 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.

Home | Main Index | Thread Index | Old Index