[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 01/12] x86/boot: introduce boot module types


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 6 Nov 2024 09:45:31 -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=1730904337; 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=/YLcxsoOOu39VuRd5DmMwgFPCASmAmv3+ERaiS3X7MQ=; b=TyrgM4tfmFrTNMZPvB+U+n3B6Y8i/CqPw93kAwB8JZhKuWO7xcgag1685p06hQ3sdQ+TYAN0LQnTkG/+YA3jRl3EUtn1foCrmou/5pfHWj22FhQ5h0AxZGdGOqICIxEc03NPACIHCLBwdIOwgqGdGNGhylOdNNKzo7oqbk/8Hus=
  • Arc-seal: i=1; a=rsa-sha256; t=1730904337; cv=none; d=zohomail.com; s=zohoarc; b=jjAryP8RCLD75W8XZuG/nsK58jWXFd5YVYoqRFBsegDl7xn7f08B/7IqWkdnuU9OCPyR2s1lNE2e/FSCyslmHpQlIQzX3q1k5KjP8VjC+fzRvtr2k+UEhXeSULaX1NWnBAQn4bRgSKW/FHv+zlFZJR+RWNU7aJR8ezmJ3sLKK0U=
  • Cc: jason.andryuk@xxxxxxx, christopher.w.clark@xxxxxxxxx, stefano.stabellini@xxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Wed, 06 Nov 2024 14:45:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11/6/24 09:05, Andrew Cooper wrote:
On 02/11/2024 5:25 pm, Daniel P. Smith wrote:
This commit introduces module types for the types of boot modules that may be
passed to Xen. These include xen, kernel, ramdisk, microcode, and xsm policy.
This reduces the need for hard coded order assumptions and global variables to
be used by consumers of boot modules, such as domain construction.

Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, albeit it with
one extra suggestion.

Sure.

---
Changes since v7:
- merged the addition of microcode and xsm boot mod types

Changes since v5:
- added guard around initrd type assignment
- removed a missed rebase artifact
---
  xen/arch/x86/cpu/microcode/core.c   |  1 +
  xen/arch/x86/include/asm/bootinfo.h | 12 ++++++++++++
  xen/arch/x86/setup.c                |  4 ++++
  xen/xsm/xsm_policy.c                |  1 +
  4 files changed, 18 insertions(+)

diff --git a/xen/arch/x86/cpu/microcode/core.c 
b/xen/arch/x86/cpu/microcode/core.c
index 1fa6cbf3d364..f46464241557 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c

@@ -831,6 +831,10 @@ static int __init early_microcode_load(struct
boot_info *bi)
                  continue;
              }
+            /*
+             * Do not alter this boot module's type.  We're most likely
+             * peeking at dom0's initrd.
+             */
              data = cd.data;
              size = cd.size;
              goto found;


To make it absolutely crystal clear that ...


Absolutely, as it might not be clear to a future editor of the code.

@@ -845,6 +845,7 @@ static int __init early_microcode_load(struct boot_info *bi)
              printk(XENLOG_WARNING "Microcode: Chosen module %d already 
used\n", idx);
              return -ENODEV;
          }
+        bi->mods[idx].type = BOOTMOD_MICROCODE;

... this is deliberately not done on the scan path.

v/r,
dps




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.