From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 06B9F2050AAE1 for ; Wed, 29 Mar 2017 09:07:30 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id y18so61155286itc.1 for ; Wed, 29 Mar 2017 09:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DsecAfUeQ9NFIifN+TjwE29b625K2lCl1NC7ajDBe64=; b=J6ZXFFFHf04S65pXPtfTpX4ZAagVk+QDbws/gHeMCrCOgz2e/2R14AeELreSYjDip2 g2oyrJci9g002SxNQK9onSpu2ayoSVMT4z2nXBCRWQPfDB+HLIfoiDNdfBGkQhx0uNWQ Olf7zouhGyPg9f4LRXZ2UQmXvpYDJoV5atzVU= 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=DsecAfUeQ9NFIifN+TjwE29b625K2lCl1NC7ajDBe64=; b=JBn2SFBFX0V7eYs+PMS/1dOt2AQN9NJEqyRJBRbuBFFIzSSF0smUVEyU/bCGOPn87y 7FPmzNPvCm0klwZpxuNmOSCY8JUkokQuMD7/cTJjnb1HUK1FxDBFDa+302yQFgH9ZjYt mJmbc7W1zi6WLlVS19ahXfxVB3lgIfQhHNQvzndNt96A/mDoBCVB3DsusvUouSZrPFYa KdVa37RA9Lp5xDRgGswiTYNVEGfIqXdEUCToC36BRucil0mTgm1u8K6ulzw1++aVJQYp OmXQ/1FFX5Cgjc8KF3o89VjNf+J8vtFVbpRWsmuyea6IicflTIv1Lj/j31w4BhaxS4GS UaQg== X-Gm-Message-State: AFeK/H26+KIJSykIGjdJ/MUtyujEzjkPguGsJFBeZOeCPZDURqBYARi1WgovAhGTJddNpbbMx/Hc50AMllx08rK6 X-Received: by 10.36.89.209 with SMTP id p200mr1875685itb.59.1490803649292; Wed, 29 Mar 2017 09:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Wed, 29 Mar 2017 09:07:28 -0700 (PDT) In-Reply-To: <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> From: Ard Biesheuvel Date: Wed, 29 Mar 2017 17:07:28 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Marc Zyngier , Jon Masters , Drew Jones Subject: Re: [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:07:30 -0000 Content-Type: text/plain; charset=UTF-8 On 29 March 2017 at 17:03, Laszlo Ersek wrote: > On 03/29/17 18:02, Ard Biesheuvel wrote: >> On 29 March 2017 at 17:00, Laszlo Ersek wrote: >>> On 03/29/17 17:19, Ard Biesheuvel wrote: >>>> In general, we should not present two separate (and inevitably different) >>>> hardware descriptions to the OS, in the form of ACPI tables and a device >>>> tree blob. For this reason, we recently added the logic to ArmVirtQemu to >>>> only expose the ACPI 2.0 entry point if no DT binary is being passed, and >>>> vice versa. >>>> >>>> However, this is arguably a regression for those who rely on both >>>> descriptions being available, even if the use cases in question are >>>> uncommon. >>>> >>>> So allow a secret handshake with the UEFI Shell, to set a variable that >>>> will result in both descriptions being exposed on the next boot, if >>>> executing in the default 'ACPI-only' mode. >>>> >>>> setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceDt =01 >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Ard Biesheuvel >>>> --- >>>> ArmVirtPkg/ArmVirtPkg.dec | 8 ++++++++ >>>> ArmVirtPkg/ArmVirtQemu.dsc | 3 +++ >>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 7 ++++++- >>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 5 +++++ >>>> 4 files changed, 22 insertions(+), 1 deletion(-) >>> >>> Nacked-by: Laszlo Ersek >>> >>> This will cause everyone *at all* to set the secret handshake, and we >>> will be back to square one, where everyone just exposes ACPI and DT at >>> the same time, and delegate the decision to the guest kernel. >>> >>> And then vendors will continue to ignore ACPI testing, and they will >>> continue shipping crap in their ACPI tables. >>> >>> We might as well rip out the recent patches that implement the mechanism >>> and the policy for the mutual exclusion. >>> >>> As Leif proved so eloquently (in the pub) in Budapest during Connect, no >>> OS needs both descriptions at the same time. Virt users can make up >>> their minds about what to expose. We (RH virt) had been worriedly >>> planning to make the same proposal to Leif, you, et al, and then we were >>> happy to see the violent agreement that ensued. >>> >>> Sorry for getting political, but the kernel's unwavering preference for >>> DT over ACPI is political, and the recent edk2 patches only exist to >>> rectify that, from the firmware side. Users don't lose DT. What they do >>> lose is the (harmful) freedom of not choosing one over the other. That >>> freedom has had a terrible effect on the quality of ACPI tables shipped >>> with *allegedly* SBBR-compliant hardware. >>> >>> Feel free to diverge from this in downstream distributions, but this >>> loophole has no place in upstream edk2. >>> >>> NACK >>> >> >> OK, fair enough. How do you propose to handle this regression then? >> > > I don't. I think I am entitled to a more constructive attitude from you. I don't care about politics, but I do care about not breaking people's workflows. So if you insist on getting on your high horse and throw capitalized NACKs at me, you could at least *pretend* to care about other users than *your* downstream, and come up with some alternative.