Re: [Xen-devel] [PATCH v2 2/4] x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.12.2019 22:25, Eslam Elnikety wrote:
> On 18.12.19 13:05, Jan Beulich wrote:
>> On 18.12.2019 02:32, Eslam Elnikety wrote:
>>> @@ -725,7 +701,7 @@ static int __init microcode_init(void)
>>>        */
>>>       if ( ucode_blob.size )
>>>       {
>>> -        xfree(ucode_blob.data);
>>> +        bootstrap_map(NULL);
>>
>> As much as I like the change, I wholeheartedly disagree with this
>> aspect of it: You make it largely unpredictable when the boot
>> mappings will go away - it becomes entirely dependent upon link
>> order. And of course we really want these mappings to be gone,
>> the very latest (I think), by the time we start bringing up APs
>> (but generally the sooner the better). This is (one of?) the main
>> reason(s) why it hadn't been done this way to begin with. The
>> alternative is more complicated (set up a proper, long term
>> mapping), but it's going to be more clean (including the mapping
>> then also being suitable to post-boot CPU onlining).
>>
> 
> This change is an improvement on the current status. We get to avoid 
> xmalloc/memcpy in the case of a successful ucode=scan. The problematic 
> aspect you highlight is anyway there regardless of this patch (ref. to 
> the "else if ( ucode_mod.mod_end )" in microcode_init).

Hmm, fair point. I'm not a fan of making a bad situation worse,
but I think it's acceptable here:
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel