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). The proper, long term mapping would be a welcome change, but is otherwise independent of this patch imo.
Thanks, Eslam _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
