From owner-freebsd-arch@freebsd.org Thu Jul 12 22:46:36 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BC50102B170 for ; Thu, 12 Jul 2018 22:46:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C20AC851C8 for ; Thu, 12 Jul 2018 22:46:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl0-x22c.google.com with SMTP id p23-v6so22065plo.6 for ; Thu, 12 Jul 2018 15:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=D+yawSjL7OaiDhamNCnofoyaYLgTOLWRgi5xyMYkV/4=; b=ML956Wueg2Qh5Y/wqjFptaRuHl6vGr1LbwijptkGsVqWmADmkh8v5iatxONAxAE8Q6 nTbu9vSBz32RnCVS1ASYxXtOWZ3gGXxigYhnoHVQr092X4Tem5zJSlGYD3ltkLL73PPT RpBNGTtjHpp/0PCKuJCp2kPI7gHBLGhKzJnjOyAqbcvi0w3vx9SDnJZ0LrCeGvsKQoHh 8CDa2oP4mj9RmHpYCwnGcg9ohz6B5DZ1qNngFDcFS1gM1s+xylRz8ANT2yl5RCxwH89k hJCv1opD/yH7dZFz96qywoPzVi/Sbc5mlcWuwIZLG7663jwzMcRItDcO6P0KhssRV4Ru Oa9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=D+yawSjL7OaiDhamNCnofoyaYLgTOLWRgi5xyMYkV/4=; b=J4cF13b6nKw2lu9R6VV3LwVWWe5gXdSx7zkditZTyFUaszqtrgOe2Hncxb4Yuvsx7q OSxVRLrUCqVx3MWPYTooTgOBoMxgbt6buHGpq/DueygRnUJ3P51TqbfUq+3Pw18FrRmI I7eluOPgbTdOkh82gypH8N7DXjsf9bNtvYJpg61OZkrbmPldCA87biB3Pnw33n9JT6Qg efLpotLtqxs0Cp0me9bfaz2ilKXHmedfoxTlsSSPPGjbGV9TKpfnmlGA8u4LViMcWFPk eDTJ4cMxNttjrP2dhQ/ynQ0stkPjXVIO4JvxaFl1RsnVAjdnh571AFR3Ofm9Ktl/SGt8 d6zg== X-Gm-Message-State: AOUpUlFU4AB2kNr1mJBR3KTRrEP6SyycS/Sgq9PHGKT3qHypjZ955kai FcpK9NhKzXT2tlFEtepwhiI= X-Google-Smtp-Source: AAOMgpcvIfhBlfxlohlDcH06mA+DdLC/JYSN1n9fYU5Aww4U8+VDTX4IYQIIfqZQcvvZ/3RzqV1Ieg== X-Received: by 2002:a17:902:28e4:: with SMTP id f91-v6mr187843plb.70.1531435594857; Thu, 12 Jul 2018 15:46:34 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-107.dsl.bell.ca. [70.52.224.107]) by smtp.gmail.com with ESMTPSA id 16-v6sm18262840pfp.6.2018.07.12.15.46.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 15:46:33 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 18:46:31 -0400 From: Mark Johnston To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180712224631.GF15892@raichu> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50839.1531428749@critter.freebsd.dk> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:46:36 -0000 On Thu, Jul 12, 2018 at 08:52:29PM +0000, Poul-Henning Kamp wrote: > -------- > In message <20180712183116.GB15892@raichu>, Mark Johnston writes: > > >My plan is to extend cpucontrol(8) to determine the > >correct microcode update for the running system, and have the devcpu-data > >port install the corresponding file to /boot/firmware. > > This is problematic when a diskimage is migrated to a different CPU, > only on the second reboot on the new hardware are you certain to > have the correct microcode. > > For images which are resurrected on demand on whatever hardware is > available this really problematic. I can think of three ways to address this case: 1a) Always load all of the updates as a single file, and select the correct update during boot. As I pointed out, this wastes some memory (a couple of megabytes currently). On at least amd64 it doesn't look very practical to release the pages backing the update file back to the VM. That is, I don't think we can easily "shed" the preloaded file data once the correct update has been selected and saved. 1b) Have the devcpu-data port operate in one of two modes: either the port selects the update for the current machine, as I outlined in my original mail, or it concatenates all of the updates as in 1a) and the kernel selects the correct update. This way we'd only waste memory if the disk image is to be shared among multiple machines. I'm not sure what the mechanism should be for selecting the mode. 2) Install all updates to a directory under /boot and add code to the loader to perform the selection, and pass only the required microcode file to the kernel. This seems straightforward to me, though I'm not yet sure exactly where in the loader this logic should go.