Re: Xen boot strangeness (Was: Re: [SOLVED] Re: Xen 4.18.5_20250521nb0 not ELF binary (Was: Re: EFI and Xen))

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, May 30, 2025 at 12:02:07PM +0200, Christoph Badura wrote:
> On Thu, May 29, 2025 at 09:23:46PM +0200, Manuel Bouyer wrote:
> > On Thu, May 29, 2025 at 03:01:50PM -0400, Chuck Zmudzinski wrote:
> > > The strange part is that it is necessary to pass -c to the DOM0 in boot.cfg to
> > > actually disable com* and the bootloader does not execute the userconf=disable com*
> > > command that is present in boot.cfg when booting NetBSD/xen DOM0. The userconf=com*
> > > setting works for the boot without Xen, but with Xen the bootloader ignores that
> > > setting in boot.cfg.
> > 
> > This is because the userconf command from the boot loader doens't make it
> > to the dom0 kernel.
> > Remember that when booting Xen; Xen is the kernel and XEN3_DOM0 a module.
> > I don't know if multiboot allows passing extended informations to a module.
> 
> Every module can be passed a string.  That's even in the 0.6.96
> specification.  Took me 5 minutes to look that up.

Yes, that's what we do already for bootdev or other command line parameters.
but userconf is a structure (a list of strings actually).
For multiboot we'd need to convert it back to a single string, and
handle it on the kernel side (and make sure to no reach the string
len limit). This has not been done yet.

> 
> And even if standard multiboot doesn't allow it.  It is our bootloader code
> so we can extend it every way we like.

Not exactly. Xen comes in the way.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--