public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Marc Zyngier <marc.zyngier@arm.com>, Jon Masters <jcm@redhat.com>,
	Drew Jones <drjones@redhat.com>
Subject: Re: [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation
Date: Wed, 29 Mar 2017 18:03:58 +0200	[thread overview]
Message-ID: <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> (raw)
In-Reply-To: <CAKv+Gu9=TPULXh+oNW-zH85ZHDas7ci4OcObHNU8vuQcJTxSPA@mail.gmail.com>

On 03/29/17 18:02, Ard Biesheuvel wrote:
> On 29 March 2017 at 17:00, Laszlo Ersek <lersek@redhat.com> 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 <ard.biesheuvel@linaro.org>
>>> ---
>>>  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 <lersek@redhat.com>
>>
>> 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.


  reply	other threads:[~2017-03-29 16:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 15:19 [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation Ard Biesheuvel
2017-03-29 16:00 ` Laszlo Ersek
2017-03-29 16:02   ` Ard Biesheuvel
2017-03-29 16:03     ` Laszlo Ersek [this message]
2017-03-29 16:07       ` Ard Biesheuvel
2017-03-29 16:40         ` Laszlo Ersek
     [not found]           ` <2fb8acda-2786-e3de-e035-32d13e3f5868@arm.com>
2017-03-29 17:07             ` Ard Biesheuvel
2017-03-29 17:23               ` Laszlo Ersek
2017-03-29 17:30                 ` Ard Biesheuvel
2017-03-29 17:50                   ` Laszlo Ersek
2017-03-29 17:15             ` Laszlo Ersek
     [not found]               ` <010325b6-1c23-5da7-9df5-337619c519bb@arm.com>
2017-03-29 18:04                 ` Laszlo Ersek
2017-03-29 17:16           ` Ard Biesheuvel
     [not found]       ` <e78f315f-1e84-cc6c-ab41-fe98b842af21@arm.com>
2017-03-29 17:03         ` Laszlo Ersek
     [not found]   ` <7F72156F-3814-4CF1-8847-A7272409A85E@redhat.com>
2017-03-29 16:17     ` Ard Biesheuvel
2017-03-29 16:55       ` Laszlo Ersek
2017-03-29 17:44         ` Mark Rutland
2017-03-29 17:58           ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox