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

Re: [PATCH 2/5] x86/ucode: Fold early_update_cache() into microcode_init_cache()


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 28 Mar 2023 15:51:24 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7ZcaX2y5V1bTP0Arq0RT/OQDF/ptatLDuxmANi7x0dw=; b=D+VV9jENRT/qoEd9TV2WTMYMbYm/pIIhTjXgHxAmp9SeESirIY7JkwLn2NoNcIvROtr+TpdbNOTgj2H1XeRLjHw4dk9Zp7FmyRkSNphosZytWhGMTMFvBPGdoDVbQa5aZHLrC5juUz+Nv4GiBvr13SCvUvnjk6F1/0Q0oNNfYIWngLTjL38BAXfkw68dlUyyar2FBzcRkskXaxJIICfQpXkEvegZq5WkuNc+ucltOMQ2EShFuRqjU7Ktf8h6MKi6ovoIx7rGSIuYsuttdkfixusORoHI1XsNOFu3xZh3QzRjxFNbvtuQXPDmmX3Ziiiiv7h5fLgWK4cm2p/uYAtv8Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cXUU1SA4cIrWhYd9O3Pi6pyRGcLq/Sd2esITsCq8ghao7riLcxyAhHfb7H5OnhJnQSdNr0cFLGMeOaEb7FKgv8wLQQXPVc3BB9dKFpsmPu1Qul/eh/bJBbiWKVI4jrqT7y1yOC5GkaSPYNqVZUDl2L+WNwGHVRZrmQfZI/ormiPNSJlLULjIOkFfUiRDj1RUY2kGCL4z+Tpyar8rdH228EcjOcjQB8JVtfS07a/EfePa8vfcC8E5DYff38FUY0qbJBwd07641v/CVd8zGc7cTQlwSp7s+yJd2oSwYHWvbP/Shn6pmXOBXUFf4hy8RneFg5ZmaDV0I4lfzDKj/uTZdA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 28 Mar 2023 13:51:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.03.2023 21:41, Andrew Cooper wrote:
> It is not valid to retain a bootstrap_map() across returning back to
> __start_xen(), but various pointers get stashed across calls.

It's error prone, yes, but "not valid" isn't really true imo: As long as
nothing calls bootstrap_map(NULL) all mappings will remain as they are.

> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -755,47 +755,51 @@ int microcode_update_one(void)
>      return microcode_update_cpu(NULL);
>  }
>  
> -static int __init early_update_cache(const void *data, size_t len)
> +int __init microcode_init_cache(unsigned long *module_map,
> +                                const struct multiboot_info *mbi)
>  {
>      int rc = 0;
>      struct microcode_patch *patch;
> +    struct ucode_mod_blob blob = {};
>  
> -    if ( !data )
> -        return -ENOMEM;

This is lost afaict. To be in sync with earlier code ) think you want to ...

> +    if ( ucode_scan )
> +        /* Need to rescan the modules because they might have been relocated 
> */
> +        microcode_scan_module(module_map, mbi);
> +
> +    if ( ucode_mod.mod_end )
> +    {
> +        blob.data = bootstrap_map(&ucode_mod);

... check here instead of ...

> +        blob.size = ucode_mod.mod_end;
> +    }
> +    else if ( ucode_blob.size )
> +    {
> +        blob = ucode_blob;
> +    }

(nit: unnecessary braces)

> -    patch = parse_blob(data, len);
> +    if ( !blob.data )
> +        return 0;

... here, making the "return 0" the "else" to the earlier if/else-if.

Alternatively, if you think the -ENOMEM isn't sensible, I'm happy to
consider respective justification for its removal.

Jan



 


Rackspace

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