On 20/12/2019 09:57, Jan Beulich wrote:
> 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 <jbeul...@suse.com>
Specifically relevant to this conversation is point 2 of
https://lore.kernel.org/xen-devel/20200109193241.14542-1-andrew.coop...@citrix.com/
where having dynamic bootmap mappings seems pointless when all we're
doing is mapping RAM below 4G.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
