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

Re: [PATCH 1/2] x86/ucode: allow cpu_request_microcode() to skip memory allocation


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 8 Dec 2022 16:34:25 +0100
  • 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=LFjrw/i7rnHF1ifbMIw2RAbjfbMnu8L0QnsRWzAIIYw=; b=AyWTXFoEx3Fltb2nDHdAWATwoSLNXsH1dYCTcf7kpDZZcOwlW/bWBuPyrOTg2No8Tg1aw9tus1Cg0cgQHAlhPvCW9GpjS0RRZG9aAWsx6RGTvypKKU6+fg9v5R1aO0ALe/CScCpybJys2sdEuZBC2wjQatfGS57fFyUdBkRsjl5nXHa+1wIHcBK7ByJadAKc8hXEOwmbouFb3SEV/asqE8cdLZzmM7z4dAeHRNAkCL4NeEHaRWiWLN28Y5bwJUBpNBz0lham4IXzpLrkxMW+QuRpS6hYN3S6/lH0s9zwnW7rnOgIUZhMVRQNbNhDZqE4wcOAxTH1wOcru7sMquComQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5qdIDoIlwFFLzVXtNIxwdTblizzc4FERZ9lajCpY/JE9MMMzEKjjTgEWcEFrGKQLVUKruVtyK48qmKJgITVLDO2JGK2mqOhwQ3/RONhFHK7h3FfyDHzDI5ZC3nGTbA7zcOgQ8djsUxPLHCij1l8Urc/sNh7yh+DFSmAD6/XV/evksrDhEyD4q4NETUOCxA52e5ZGxkdQFwVvrzVytUjqPVrUd2f3NJyYSvm+GS2oOS/YvEShOXqnU0XMIhudg3G31i0WQ3z53BAB15bdEoIm/ElmXa9qVevHkAWQSDkkqP5E/fYdq2o0voqvWCshthd7VnlufgaxayoBbKfucpITw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Dec 2022 15:34:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.12.2022 14:59, Andrew Cooper wrote:
> On 08/12/2022 13:26, Sergey Dyasli wrote:
>> @@ -240,20 +240,20 @@ static const struct microcode_patch *nmi_patch = 
>> ZERO_BLOCK_PTR;
>>   * patch is found and an error occurs during the parsing process. Otherwise
>>   * return NULL.
>>   */
>> -static struct microcode_patch *parse_blob(const char *buf, size_t len)
>> +static const struct microcode_patch *parse_blob(const char *buf, size_t len)
>>  {
>>      alternative_vcall(ucode_ops.collect_cpu_info);
>>  
>> -    return alternative_call(ucode_ops.cpu_request_microcode, buf, len);
>> +    return alternative_call(ucode_ops.cpu_request_microcode, buf, len, 
>> true);
>>  }
>>  
>> -static void microcode_free_patch(struct microcode_patch *patch)
>> +static void microcode_free_patch(const struct microcode_patch *patch)
>>  {
>> -    xfree(patch);
>> +    xfree((void *)patch);
> 
> This hunk demonstrates why the hook wants to return a non-const
> pointer.  Keeping it non-const will shrink this patch quite a bit.

Alternatively it demonstrates why xfree() should take const void *,
just like e.g. unmap_domain_page() or vunmap() already do. We've
talked about this before, and the argument hasn't changed: Neither
unmapping nor freeing really alters the contents of the pointed to
area from the perspective of the caller, as the contents simply
disappears altogether.

Jan



 


Rackspace

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