Re: port-xen/59451: XEN3_DOM0 kernel finds the wrong root device

["Chuck Zmudzinski via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-xen/59451; it has been noted by GNATS.

From: Chuck Zmudzinski <frchuckz%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-xen/59451: XEN3_DOM0 kernel finds the wrong root device
Date: Mon, 2 Jun 2025 16:51:56 -0400

 On 6/2/2025 4:49 PM, Chuck Zmudzinski wrote:
 > On 6/2/2025 4:25 PM, Michael van Elst via gnats wrote:
 >> The following reply was made to PR port-xen/59451; it has been noted by GNATS.
 >> 
 >> From: mlelstv%serpens.de@localhost (Michael van Elst)
 >> To: gnats-bugs%netbsd.org@localhost
 >> Cc: 
 >> Subject: Re: port-xen/59451: XEN3_DOM0 kernel finds the wrong root device
 >> Date: Mon, 2 Jun 2025 20:21:10 -0000 (UTC)
 >> 
 >>  gnats-admin%NetBSD.org@localhost ("Chuck Zmudzinski via gnats") writes:
 >>  
 >>  > If I create a wedge, say it's dk2, on a host Xen dom0 system that
 >>  > is set to be the virtual disk of a Xen domU and in the guest
 >>  > domU I write a disklabel on that virtual disk, will those partitions
 >>  > on the virtual disk in the guest domU show up on the host Xen dom0
 >>  > system as devices with names like /dev/dk2a, /dev/dk2b, etc.?
 >>  
 >>  The partitions will not show up. The dk driver doesn't know
 >>  anything about partitions. You can't open a partition, there
 >>  are no ioctls that handle partition information. The bits of
 >>  a disklabel on the storage are just bits that you can read.
 >>  
 >>  The disklabel command can be told to read the bits from a file (-F),
 >>  and that also works for a wedge device. But that would only
 >>  print the disklabel bits, otherwise it has no meaning for the
 >>  Dom0.
 >>  
 > 
 > So trying to catch the case of a user setting bootdev=dk2a in boot.cfg is
 > just trying to catch a case when the user made a mistake. It seems unlikely
 > to happen because the user will see never see devices named dk2a on a dom0
 > system. Most likely, it a user did that, your proposed patch would strip
 > off the a and set booted_partition to 0 and it would most likely just work
 > if dk2 was the correct root device.
 > 
 > If the user set something like dk2e, then booted_partition will be 4 I think,
 > but in my testing the code more or less ignores booted_partition, even if
 > it is a garbage value, in the case of bootdev being set as a dkXX device in
 > boot.cfg. In my case, it was -15: '2' - 'A'. That bad value was actually
 > present in a function in init_main.c where there is a KASSERT to check if
 > booted_partition is in the expected range (>= 0 or < MAXPARTITIONS), but the
 > KASSERT never got triggered in my testing.
 
 Oops, the KASSERT checks it is not in the unexpected range (>= 0 or < MAXPARTITIONS).