From owner-svn-src-head@freebsd.org Sun Jun 17 12:50:46 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 85AB5101DDB7 for ; Sun, 17 Jun 2018 12:50:46 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 1004F6D341 for ; Sun, 17 Jun 2018 12:50:46 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw0-x242.google.com with SMTP id j134-v6so4811252ywg.4 for ; Sun, 17 Jun 2018 05:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VHLWHiWVKKbO3K/0cw2wFWORNou3JKJ6eUrJGucxcwM=; b=mH2HGzejZSaIDMsztqrIKewrhBieJ7PNu7JrIr4uCS47bqcovkrD3L9SGyGWlBk7NV V/zvgRrZPuwVUjVBkdOl7GXYzDlC9tsiwAOk/HnzzIySAu5axEni2IVu3BhaLuofqp2p gNNdryHN017rFz9nxJe4353doseIhefZA/kBOnwIYRJqLk7jZvyeoD7xC/k1aU5Phn9x i6PuNBfzi9pSKxKXNdRH4jY342ihG9axHMInPUcqjuQy5t17aIelugPiBV4dgWLHmwCn f41NpAKg2XviMliz3UiKuxXnlSGfrbcU4p7r36GNnWTF0LqBJOzYH6gcUBdGgLo7vG39 iAhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VHLWHiWVKKbO3K/0cw2wFWORNou3JKJ6eUrJGucxcwM=; b=kB6N+EQ3xSMTtjVwt8enkVYZs76ZukD3qGN8z34EAFJKp0LMOfzl+Xjkd9fNRXUbrm oHvh6YmvYy7Llq8a5SbZQzQqfdA+PJm32KxpFQVodN5dr0++7xUnZ8DCsbmHB4jpRxYP 0TEuRmWmtayiMuvMTrzI0AA2LmkUp/yrjzPWKn+YIB2NPgefoIYTUlzOferhhJf/QJhJ Z30x5PzZxzmR/Mp7Mw3BIq6kMx/ufYEOin+67uRc+gNb7ALdUbTQ1/TV0s+BU/YMs24a Iqpex/mVfjbcmKjP6JG8eiUvAXlBzsRKQ1wmtTNDgJpNgff/rt0d1kuMaXWcDwnxOyFO MFPg== X-Gm-Message-State: APt69E1/UZLnngwTCGq0Iruin5iPx/iRlywprz8hbk4L7K/IMH7mP806 e9UjiC3Vmxid5g+qPQwYlrLPx6zcwHHiLgAPuqW3MQ== X-Google-Smtp-Source: ADUXVKKFr9rHt1JE+tEVtzwvYfzNNHWvUGK8nDlEU4lMziZQJvOMydFtAsmOLz/zKLxaUT3Fy9OpU/FTeAeCWv5FFjA= X-Received: by 2002:a81:b86:: with SMTP id 128-v6mr4228165ywl.214.1529239845123; Sun, 17 Jun 2018 05:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:db86:0:0:0:0:0 with HTTP; Sun, 17 Jun 2018 05:50:44 -0700 (PDT) In-Reply-To: <20180617123634.GB18322@pesky.lan> References: <201805221435.w4MEZXnW041963@repo.freebsd.org> <20180613140731.GA54540@raichu> <20180617123634.GB18322@pesky.lan> From: Oliver Pinter Date: Sun, 17 Jun 2018 14:50:44 +0200 Message-ID: Subject: Re: svn commit: r334046 - head/tools/tools/intel-ucode-split To: Mark Johnston Cc: Eitan Adler , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 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:50:46 -0000 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: > > >> On Wednesday, June 13, 2018, Ed Maste wrote: > > >> > > >> > On Tue, 12 Jun 2018 at 18:17, Sean Bruno > wrote: > > >> > > > > >> > > On 06/12/18 16:05, Oliver Pinter wrote: > > >> > > > On 5/22/18, Ed Maste wrote: > > >> > > >> Author: emaste > > >> > > >> Date: Tue May 22 14:35:33 2018 > > >> > > >> New Revision: 334046 > > >> > > >> URL: https://svnweb.freebsd.org/changeset/base/334046 > > >> > > >> > > >> > > >> Log: > > >> > > >> intel-ucode-split: add -n flag to skip creating output files > > >> > > >> > > >> > > >> Sponsored by: The FreeBSD Foundation > > >> > > >> > > >> > > >> Modified: > > >> > > >> head/tools/tools/intel-ucode-split/intel-ucode-split.c > > >> > > > > > >> > > > Hi! > > >> > > > > > >> > > > Could you please MFC the intel-ucode-split related commits to > > >> > 11-STABLE? > > >> > > > > > >> > > > Thanks, > > >> > > > op > > >> > > > > >> > > Do you need it in base for some reason? This code is already in > the > > >> > > devcpu-data port and is used when the port is built. Its not > needed for > > >> > > anything AFAIK. > > >> > > > >> > Indeed, the real use in FreeBSD is via the devcpu-data port; I > > >> > committed it to src/tools/ for collaboration and testing. I'll merge > > >> > it to stable/11 if it will be useful for someone, but am curious > about > > >> > the use case. > > >> > > > >> > > >> > > >> 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. _______________________________________________ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org" >