[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/12] x86/boot: eliminate module_map
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 7 Nov 2024 10:08:37 -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=1730992126; 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=KSjlVB/tCxG/hK6mCg5S2Bydfu62JEN8jSgv282MD+0=; b=X3lKTXtGu4FSK0oA1hm8hRYv+l/GX9MkEgpb2JIZvTwJeLm7jE4hMLpZ5s3bIu9x4lZM/r2ROcaT4dEn7yQo8BTGQACe0+0dMxzxGdwGVClFzsCu59x8UeCS3bMsg3rJsTloPZ/xva2KwM+Da2BCRVs2ViGtgtspOmCUxBQJImM=
- Arc-seal: i=1; a=rsa-sha256; t=1730992126; cv=none; d=zohomail.com; s=zohoarc; b=WjZS1+1JGHtrkOwzTZT5R6DsIKJilWtlfqoU+DMscyvBB5qonaIEbO8VlptOfgR6BTwuDMh2mWSfacwC1Axo0oPtiBgp1LByOf4QoU4sFFpRjH1sf18toVUDETZzUuoPsMxgC/IRYSHv7rTQdnfDdRO39qRxngGpUbR8sCSEIkw=
- 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: Thu, 07 Nov 2024 15:08:57 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11/7/24 05:05, Jan Beulich wrote:
On 02.11.2024 18:25, Daniel P. Smith wrote:
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -790,15 +790,13 @@ static int __init early_microcode_load(struct boot_info
*bi)
if ( opt_scan ) /* Scan for a CPIO archive */
{
- for ( idx = 1; idx < bi->nr_modules; ++idx )
+ for_each_boot_module_by_type(idx, bi, BOOTMOD_UNKNOWN)
{
+ struct boot_module *bm = &bi->mods[idx];
pointer-to-const? You really want to get used to applying const to pointed-to
types whenever possible. IOW ...
Yes, I have been trying to be more diligent to add them when possible.
To the point that I have had to unwind some due to writes that must be
done in later function calls they get passed. Obviously this is not one
of those case and can fix this one.
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -33,22 +33,18 @@
int __init xsm_multiboot_policy_init(
struct boot_info *bi, void **policy_buffer, size_t *policy_size)
{
- int i;
+ unsigned int i;
int rc = 0;
u32 *_policy_start;
unsigned long _policy_len;
- /*
- * Try all modules and see whichever could be the binary policy.
- * Adjust module_map for the module that is the binary policy.
- */
- for ( i = bi->nr_modules - 1; i >= 1; i-- )
+ /* Try all unknown modules and see whichever could be the binary policy. */
+ for_each_boot_module_by_type(i, bi, BOOTMOD_UNKNOWN)
{
- if ( !test_bit(i, bi->module_map) )
- continue;
+ struct boot_module *bm = &bi->mods[i];
... same here (and likely elsewhere in the series).
Nope, you can't const this one as that will cause this is at the tail
end of the loop to fail:
+ bm->type = BOOTMOD_XSM_POLICY;
v/r,
dps
|
