Re: [PATCH v3 01/16] x86/boot: introduce boot domain

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

V/r,
Daniel P. Smith
Apertus Solutions, LLC

On 4/16/25 10:06, Jan Beulich wrote:
> On 16.04.2025 16:00, Daniel P. Smith wrote:
> > V/r,
> > Daniel P. Smith
> > Apertus Solutions, LLC
> >
> > On 4/16/25 09:33, Jan Beulich wrote:
> > > On 16.04.2025 15:02, Daniel P. Smith wrote:
> > > > On 4/10/25 16:56, Jason Andryuk wrote:
> > > > > On 2025-04-10 11:01, Jan Beulich wrote:
> > > > > > On 10.04.2025 15:09, Daniel P. Smith wrote:
> > > > > > > On 4/9/25 02:24, Jan Beulich wrote:
> > > > > > > > On 08.04.2025 18:07, Alejandro Vallejo wrote:
> > > > > > > > > From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > > > > > > >
> > > > > > > > > To begin moving toward allowing the hypervisor to construct more
> > > > > > > > > than one
> > > > > > > > > domain at boot, a container is needed for a domain's build
> > > > > > > > > information.
> > > > > > > > > Introduce a new header, <xen/asm/bootdomain.h>, that contains the
> > > > > > > > > initial
> > > > > > > > > struct boot_domain that encapsulate the build information for a
> > > > > > > > > domain.
> > > > > > > > >
> > > > > > > > > Add a kernel and ramdisk boot module reference along with a struct
> > > > > > > > > domain
> > > > > > > > > reference to the new struct boot_domain. This allows a struct
> > > > > > > > > boot_domain
> > > > > > > > > reference to be the only parameter necessary to pass down through
> > > > > > > > > the domain
> > > > > > > > > construction call chain.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > > > > > > > Reviewed-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> > > > > > > > Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> > > > > > > I have to object because the meaningless rename is going cause
> > > > > > > significant pain in the rebase of the follow-on series for no improved
> > > > > > > code clarity.
> > > > > > Sorry, then an incremental patch undoing the rename that happened (with
> > > > > > appropriate justification) will need proposing - the patch here has gone
> > > > > > in already.
> > > > > Coming from a Linux background, ramdisk seemed more natural to me.  But
> > > > > looking at hvm_start_info, the fields are called module there.  And
> > > > > since we shouldn't tie this to the Linux naming, the more generic
> > > > > "module" name seemed fine to me.
> > > > Again, as I have stated, ramdisk is not a Linux only concept. In fact,
> > > > as Jan points out, initrd/initramfs are Linux specific implementations
> > > > of a ramdisk for which Xen doesn't even fully support. I am inclined to
> > > > ask the inverse of why hvm_start_info uses the name module. But that
> > > > aside, let's consider the fact that the field is only populated by the
> > > > device tree when a module type of BOOTMOD_RAMDISK is matched. And all
> > > > the uses of the field are when its value is stored into a local variable
> > > > called initrd.
> > > >
> > > > Though the biggest irony is that generally obtuse abstraction are
> > > > routinely blocked unless there is a tangible future case. Yet none was
> > > > offered in the comment. Thus on that principle alone, a request for a
> > > > tangible future use should have been requested and provided for the
> > > > change to be considered.
> > > Does it even need to be a _future_ use here? Aren't you working on
> > > abstracting domain creation, suitable (in principle) for all architectures?
> > > Isn't therefore a more generic name (as "module" is) preferable over a more
> > > specific one?
> > Yes we are trying to build a future capability, but my point is let's
> > consider all possible known OS's start up today. What other boot module
> > could potentially be passed in that is exclusive of a ramdisk, thus
> > allowing a multiplex of the field. And the answer is none.
> Is it? What if you are to start a nested Xen with its own kernel, initrd
> and perhaps even an XSM policy "module"? Or anything else that is multi-
> module capable (possibly but not necessarily because of having started
> out as multiboot)?
As you said on the v2 thread, just one other OS also using such a 
concept doesn't mean much.
With that said, as I am sure you are well aware of, the nested example 
is a far more complicated situation which there is currently no good 
abstraction in use.
And btw, as far as ramdisk usage goes, I would be remised not to mention 
that another significantly large OS uses a ramdisk for boot, and that 
would be Windows. Windows leverages a ramdisk as configuration store 
between the winlaoder and tcbloader when doing a DRTM boot.
v/r,
dps