From owner-svn-src-head@freebsd.org Sun Jun 17 12:57:20 2018 Return-Path: Delivered-To: svn-src-head@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 CB067101E155; Sun, 17 Jun 2018 12:57:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 3F7916D791; Sun, 17 Jun 2018 12:57:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id z6-v6so11876176wma.0; Sun, 17 Jun 2018 05:57:20 -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=J977th4S7twX6i1moKUOYQ1GtW7z7JupoLe+rdDy/e0=; b=VJnZuRSgpJjJOFWK5cimAZJiS+77X/W6YyKqMjeywGcS+Ce1Bokv8yIBtvoHBdtJfY GpGvFhNoBPIeB3d/+bxGSgoAIezDyTvS8aO1y7VkZt1Rr3/mMt/eo/7tT+sIDNMRFYnX hwbXiLXJBTL0/WDIjQnMsAPNO1x9h7mt+LS5BLn27w5H1mKlVZOUdlsXDK2KnsD8l6Qn zbLdBJF6w9eUL7QNQ5drnuRhUycJ/tD32w/bkLEDI8mGbZHX+CpLlpLKoIw6GXD0ok+w KRmrCpNaG9GtIqOEA0pw4jhPznSv7VaOWobj54BDtW9aTIXT3uE3flynY1FDHqWhQDws fGAA== 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=J977th4S7twX6i1moKUOYQ1GtW7z7JupoLe+rdDy/e0=; b=tnX+MbycsLpeAOjhpr0TyIwb3Jsj1EFip4lGFo0IpDlGElGbilM5z8tWzHgLE9UIBt cHADadRRbf7WVo5n870cuo0IOq+PZFPHw+aFYRqq47NBrbmRCJbBF0jKSSP+AqSIAD7N CEHzMJoSBGFIUNEVS2Kk/MP/8i+b1bfeiA8FR+4GDLLRc1hQvEbfOsOtxXjcRA/RBWPW iILlgzNjskYXXGH9QpAa0QACYpBIS0n2MExUaLELL3IfiYanzc0Vl2FX+BrWp0/5SXpd p8yJi9xG1PwOxyHYSiIfNNbdRl54i7ZzZb34MbkZyq2N/O5+/IubOleON2uK1Bo0e6xl iC7w== X-Gm-Message-State: APt69E2AB+H2MqJFdpjgLwG0F9qQeuAL7oInXos9xVgsp6SSqNrYYkA9 ahYs+I8nZTLxWjO7nRO1MIM= X-Google-Smtp-Source: ADUXVKJ6mZwa/TtnXtxfgrrVOHWEG82IkQBwCs+mboMNOYl8JqXj9WMMftMEUYiRYSSUuIwfhUY0Kw== X-Received: by 2002:a1c:908b:: with SMTP id s133-v6mr6305127wmd.35.1529240239189; Sun, 17 Jun 2018 05:57:19 -0700 (PDT) Received: from pesky.lan (84.32.136.95.rev.vodafone.pt. [95.136.32.84]) by smtp.gmail.com with ESMTPSA id k17-v6sm7964272wmc.23.2018.06.17.05.57.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jun 2018 05:57:18 -0700 (PDT) Sender: Mark Johnston Date: Sun, 17 Jun 2018 08:57:16 -0400 From: Mark Johnston To: Oliver Pinter Cc: Eitan Adler , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers Subject: Re: svn commit: r334046 - head/tools/tools/intel-ucode-split Message-ID: <20180617125715.GC18322@pesky.lan> References: <201805221435.w4MEZXnW041963@repo.freebsd.org> <20180613140731.GA54540@raichu> <20180617123634.GB18322@pesky.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 12:57:21 -0000 On Sun, Jun 17, 2018 at 02:50:44PM +0200, Oliver Pinter wrote: > On Sunday, June 17, 2018, Mark Johnston wrote: > > > On Sat, Jun 16, 2018 at 06:25:03PM -0700, Eitan Adler wrote: > > > On 13 June 2018 at 07:07, Mark Johnston wrote: > > > > On Wed, Jun 13, 2018 at 01:46:34AM +0200, Oliver Pinter wrote: > > > >> I'm considering to write an in kernel microcode update facility, > > based on > > > >> firmware(9), and in first idea it would be nice during the generation > > of > > > >> firmware modules. > > > > > > > > FWIW, I'm working on this for 12.0 and was planning to describe my > > > > proposal on -arch in the next couple of weeks. For my purposes at > > > > least, firmware(9) isn't suitable. We'd like to ensure that updates > > are > > > > applied before the kernel does CPU identification, and that happens > > > > quite early during boot. This places some constraints on the > > > > implementation which exclude firmware(9). > > > > > > Naive question, knowing nothing about firmware(9), but why can't it be > > > enhanced to work that early? It seems there might be other use-cases > > > for very-early-boot firmware application. > > > > The constraint means that almost none of the standard kernel APIs (e.g., > > malloc()) are usable at the time that the update is to be applied. It > > doesn't seem practical to me to try and implement firmware(9)'s > > abstractions under such limitations. Further, because microcode > > updating is an platform-specific operation, in this case it's preferable > > to tie the implementation to that platform's code. > > > How do you plan to put the firmware into memory? Preload it with the loader > or compile into kernel module or with somehow early fs access from kernel? > > Or instead of updating the microcode from kernel, do the whole process from > the loader? > This will be problematic in resume case. The loader can be instructed to load arbitrary files into memory before beginning execution of the kernel. Currently, my plan is to check for a loaded microcode file early in the MD startup code, and apply the update if one is present. This will be done following a resume as well.