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

Re: [PATCH v6 17/44] x86/boot: convert microcode loading to consume struct boot_info


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 19 Oct 2024 11:49:36 -0400
  • 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=1729352980; 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=G7BBTQCFyf31hu8f1N++zMSNLcexIXcZNf4Ecwut6ls=; b=G+ewrBlvjtEKyQ4FzFKmxOiyYrvOFeKV2BX0KX6Z43+y9VWDiAN9Js86QTxzBepLvZejVwEkSCSpT6tSVRAEoeD4ldNg/8b0WrN8fhBeTymQB/o/FIl1hNCnYkkhVBcvqySS1ONiFAT24b6gVQnKjtcAmfXnIoTigFJeZ7MOU5U=
  • Arc-seal: i=1; a=rsa-sha256; t=1729352980; cv=none; d=zohomail.com; s=zohoarc; b=EGW+NUfNhnrXYGATiZzOVacHAQ+w/+hYQz3c6EiY4SUDmS46sEysjEt8kSgKeVm10G0UNYPQBDXuumcwGSF0dWg/AstfzonYMxahOhG6jV/JzSdHCoEIzk29QfAK57BOt/M+cZ56JCJ/fMyJcsYPgOGgBeUVr2bxYEQSCRjZQsQ=
  • Cc: jason.andryuk@xxxxxxx, christopher.w.clark@xxxxxxxxx, stefano.stabellini@xxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Sat, 19 Oct 2024 15:50:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10/17/24 21:14, Andrew Cooper wrote:
On 17/10/2024 6:02 pm, Daniel P. Smith wrote:
diff --git a/xen/arch/x86/cpu/microcode/core.c 
b/xen/arch/x86/cpu/microcode/core.c
index 8564e4d2c94c..22fea80bc97e 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -178,16 +177,16 @@ static void __init microcode_scan_module(
      /*
       * Try all modules and see whichever could be the microcode blob.
       */
-    for ( i = 1 /* Ignore dom0 kernel */; i < mbi->mods_count; i++ )
+    for ( i = 1 /* Ignore dom0 kernel */; i < bi->nr_modules; i++ )
      {
          if ( !test_bit(i, module_map) )
              continue;

Somewhere in this series, it would be nice to purge the these "module 0
is dom0" special cases.  I'm not sure where best in the series to do it,
and it may not be here.

Later, in "x86/boot: remove module_map usage from microcode loading" you
convert this test_bit() into a type != UNKNOWN check, but the pattern is
used elsewhere too.

How about a for_each_unknown_module(bi, bm) helper?  (which at this
point can even use module_map in scope).

So I do have the first_boot_module_index() iterator which I am using to effectively open-code your suggested for_each_unknown_module() in one or two places. I can introduce that helper when I first do the open coding, though I would like to make it a little more generic. I would prefer to do it as for_each_bootmodule(bi, bm, type). There is a scenario/enhancement that I would like to get to that may require doing an iteration on a type other than BOOTMOD_UNKNOWN.

Would you be okay with leaving the module_map usage at this point and changing over to the for_each_bootmodule() when it is dropped? As I see it, otherwise I would have to make the helper initially work with module_map only to turn around and drop it when module_map goes away. At least to me, seems like unnecessary churn unless you see a way without causing the churn in the helper.

If you introduce it at this point, then I think the churn later in the
series reduces marginally, and I think it removes all the "careful not
to look at dom0" special cases.

In the end, yes I want to get a way from that, once domain builder is introduced, it will be possible to provide the boot modules in any order.

v/r,
dps



 


Rackspace

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