Re: kern/55958: pciback.hide parsing error

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

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

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: Aleksey Arens <aza.sea.agenda%gmail.com@localhost>, jnemeth%cue.bc.ca@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        gnats-bugs%netbsd.org@localhost
Subject: Re: kern/55958: pciback.hide parsing error
Date: Fri, 29 Jan 2021 00:15:55 -0800

 On Jan 28, 22:33, Aleksey Arens wrote:
 }
 } >      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.
 
      Keep in mind that the NetBSD kernel itself is the module.
 You're not loading a module into the NetBSD kernel, you're loading
 a module into the Xen kernel (Xen is the host OS).  The arguments
 are for the kernel itself, not a module, so you need to find where
 the kernel parses its own command line.  This has nothing to do
 with NetBSD modules.
 
 }-- End of excerpt from Aleksey Arens