Re: kern/55958: pciback.hide parsing error

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

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

From: Aleksey Arens <aza.sea.agenda%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/55958: pciback.hide parsing error
Date: Wed, 27 Jan 2021 00:54:14 -0800

 >  Yes. But the Xen kernel probably needs to copy it at some point (even if
 >  it doens't know what it's copying). I'm not sure if it can copy somethin=
 g
 >  arbitrary long (it may be limited e.g. to a page size).
 >
 
 As I understand it, Xen reads the cmdline string from an offset in the
 module image passed-in to it.  Cf.
 https://fossies.org/linux/xen/xen/arch/x86/setup.c#l_760
 
 >  But there's something strange here: Xen is supposed to use multiboot, no=
 t
 >  the NetBSD native boot protocol. In multiboot, the structures from
 >  bootinfo.h are not supposed to be used.
 >
 
 Correct.  However, those arguments are not the ones being passed to
 Xen, but to the module image that is being loaded by Xen.
 
 >  So I guess that the problem is more that /boot abuses bi_modulelist_entr=
 y
 >  for internal structures in the multiboot case. The problem can probably
 >  be fixed in /boot without changing bootinfo.h at all.
 
 In principle, yes.  However, in that case, a different Xen-specific
 format will need to be defined.  Maybe a copy of bi_modulelist_entry
 should be made, mentioning xen in its name?  This is a piece of
 bootinfo that is Xen-specific, and currently, it appears that the same
 structure has merely been reused to cover both cases.
 
 At any rate, an ability to use longer =E2=80=94  and ideally variable-lengt=
 h =E2=80=94
 strings for /netbsd's boot arguments won't hurt in the long run,
 though *that* specific topic (i.e. re: /netbsd's arguments) could
 become a matter for another ticket.  Right now, setting up a special
 case for Xen (with fixed buffer length of e.g. 512, being a half of
 Xen's limit of 1024 for the whole command line) might as well be more
 than sufficient.