[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 01/15] x86/boot: introduce boot domain
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 4 Dec 2024 14:16:59 -0500
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733339823; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=StuxpsyUAmqaaCDxtlpMU/g74F5wKRQHXEQ4hk5YQys=; b=Ht7tj7GYEYRLqNjIcmNJWhUGThoocP0khOqxbU1DQby0LTPaQC2jK63Rzgk7THPEhC8YBlKgS9EugC6RM1g3q5/Mnmnr51yxjHpVxD8En0BEi3npzwH/uank41OaVmItz9v8o7BSaFdWgO1xDzdwWWF9SkvlGoXBiCYPfAbP/js=
- Arc-seal: i=1; a=rsa-sha256; t=1733339823; cv=none; d=zohomail.com; s=zohoarc; b=JUIFAYTptMPu+D+S5wJzODsBXuz13Y95U2dMv2fbM+ykBQ7hQjogvnv05cDXt9pS9QSMuHI05GLEcTWHPn1iGL9wtmx8OZzpkiN+nhNGWxC2R8SEBXe4+xWg5xtDo4XwmSSgsFvLUd8acETBQbz4ZVIDVfb2IMNGJhhiZaf78vI=
- Cc: jason.andryuk@xxxxxxx, christopher.w.clark@xxxxxxxxx, stefano.stabellini@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 04 Dec 2024 19:17:17 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 12/2/24 04:57, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
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.
Why does this need to be a per-arch header? Wasn't one of the goals to unify
things as much as possible?
Correct and at this point the level of unification is this series that
provides a common device tree definition.
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d,
unsigned long initrd_len);
int dom0_setup_permissions(struct domain *d);
-struct boot_info;
-int dom0_construct_pv(struct boot_info *bi, struct domain *d);
-int dom0_construct_pvh(struct boot_info *bi, struct domain *d);
+struct boot_domain;
+int dom0_construct_pv(struct boot_domain *bd);
+int dom0_construct_pvh(struct boot_domain *bd);
I'm wondering: Just a few commits ago you moved these to boot_info. Now you
move them to boot_domain. Why the extra churn, and what further transformations
are to be expected?
Introducing all the abstractions and adjusting all interfaces in one go
was deemed too complex to review and originally done that way because
doing it incrementally would require making changes to changes.
Therefore it is an artifact of breaking the larger change into an
incremental introduction of the changes. When the multi-domain builder
is incrementally introduced, there will be renaming in place, splitting,
and renaming as function are moved.
v/r,
dps
|
