[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 2/4] x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Eslam Elnikety <elnikety@xxxxxxxxxx>
- Date: Thu, 19 Dec 2019 22:25:32 +0100
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Paul Durrant <pdurrant@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, David Woodhouse <dwmw@xxxxxxxxxxxx>
- Delivery-date: Thu, 19 Dec 2019 21:26:04 +0000
- Ironport-sdr: WTOrV5pizNEMWPJlTbb+1+NSE0qlu4iCW7H8uOpqKMMSCj30/1CMaZ+7dLi2feOPRZKcQs2L7E Trxm1N1aFfVA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
