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:49:37 -0400

 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.