From owner-svn-src-all@freebsd.org Sun Jun 17 12:36:39 2018 Return-Path: Delivered-To: svn-src-all@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 0B6BF101D7F2; Sun, 17 Jun 2018 12:36:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 746826CD8A; Sun, 17 Jun 2018 12:36:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id w10-v6so14045202wrk.9; Sun, 17 Jun 2018 05:36:38 -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=Zi2Bo2n1jtSyQGGTCFCks04jDiG2qKN4wFeQuL8t8rA=; b=VWTXJuOXLnibkbna3qhZkenzulgSkPZM5iDQj58+YH89ERxtwB3HIw8eODOsNzLj5s ZIZdFQYRqW9FaF9zEhR0VeNpFfXXbmRwBMCkoVB4GeZv4ep8w8sYU2amVPilpG5aAKJY OVGn5YWo6DobOWQZD3IVOaKV0rnv+NSNqILiFeX7G5fqpLrSxIGmFsSSgv60iC42+A9t /+zgXUGaDA7CHia6rAQDP1y/+qfjrS4UIkSfzypIkY395ilGdG7kgCy6ttvzb6qMbSrB jcuPrQ7Dz0Ux1mitmxdiOx3ZSPVbZoRUwL6z8qzp/ieOyCQm1xoBJORROr61pu33vno5 B/pg== 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=Zi2Bo2n1jtSyQGGTCFCks04jDiG2qKN4wFeQuL8t8rA=; b=Z4trjxYp6H/69DBpBKirbTHEdLK/rVv0Tt6yb0MyAffE2pBuLrEGa4qnE6kBf4iQTq iPGyX2JvFpMTix/ZluAQ6trxbR5IpH8Ed1FPZ7BXsoR3YzfIqEYZRT1p4GhLLB2LUHre JmBg1KW1StnuDADskxgIKC8Yo8eBcxzBe8sWKJWIBzgbQ5c5+YuTe2gHWhWf59VgU5xd QNID9k59pMJUbx4plx3JrQOS491MiVjdEd9WTZKOF4kRL6k583Il8fpqDUgH29SE+dpZ VQebv0ovnSFHCRWfm74gbRFCV7riRRb+m4l5v7uUzpDP5lyBoOIOgGfTesFxP6yUyXOC imHg== X-Gm-Message-State: APt69E1uCYWP6cM1MIW6fYO2u3UX9L8628xdG02tmbg1RrY/HZes3r01 eFiIHu7YaTj9hGZvwuA8Y9TWDA== X-Google-Smtp-Source: ADUXVKIRywbDKbv6L2f3Ik1FjTXDE8Yq6XSH7QUp72SoUogB5SNPeD58H8/WaPyNtm59SV6vXCw0ww== X-Received: by 2002:adf:93c6:: with SMTP id 64-v6mr7195669wrp.119.1529238997430; Sun, 17 Jun 2018 05:36:37 -0700 (PDT) Received: from pesky.lan (84.32.136.95.rev.vodafone.pt. [95.136.32.84]) by smtp.gmail.com with ESMTPSA id h11-v6sm11850494wrs.85.2018.06.17.05.36.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jun 2018 05:36:36 -0700 (PDT) Sender: Mark Johnston Date: Sun, 17 Jun 2018 08:36:34 -0400 From: Mark Johnston To: Eitan Adler Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r334046 - head/tools/tools/intel-ucode-split Message-ID: <20180617123634.GB18322@pesky.lan> References: <201805221435.w4MEZXnW041963@repo.freebsd.org> <20180613140731.GA54540@raichu> 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-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 12:36:39 -0000 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.