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:53:21 -0400

 On 6/2/2025 4:51 PM, Chuck Zmudzinski wrote:
 > 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).
 
 Oops again, I had it right the first time. Sorry for the noise. I'm getting old...