From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 141DA21A04839 for ; Fri, 31 Mar 2017 03:16:16 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f84so36530845ioj.0 for ; Fri, 31 Mar 2017 03:16:16 -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=5ZQ7CTWp/KhTp0Y6R+Me7sB4fQrQ7Nh6g8cL8lIS99A=; b=Fugx1UBKqNCGEiViGHtg+UCO2VDN90euhUVoC4i1sIJYP0y4F3++7A63fkYooRCKHE rCd0KoVVCnDQN/+eVa79XeIRQKrSO9QLNmP+QRk7A5Urb4nYD9F0Rc0GbGykNx5CJUJL jiwgPdDXlsHQS0Ht9QJG1Nl0C6AZffvIF4uDc= 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=5ZQ7CTWp/KhTp0Y6R+Me7sB4fQrQ7Nh6g8cL8lIS99A=; b=AR/TIQEVfGVKS6pGGPmSTmRW6DXmSkKRtVY36cWF5sKHEnavGHdTNkrG2aobs21eyl NiaKtkbl5CXjE0IvqA13ZczPoEk0xgEx6NbJ+rLvczVfKvAz0ru51DPG9cpHO2pAJ5PQ 39LxWJDcaFmEcXUfj2k9owi73F2NsM3PPQ0JAqnUPRxSSNyA13fx6EBYO9tcuZT/vHHf qskoRkAA1HCO7lwjXQ4QONGoVSFK+uYLOzzewsBU6oGArS7fR9d2nliyHcJ4wdkpNW/c s3FDUbJyaxcHV/J3sVAwl3pzBMg8oLCWbZITVWhC5eMLzjiZ/Fwv5sXpmVa/whfQbxuV odmw== X-Gm-Message-State: AFeK/H3L2Z1Qh5FDbOt5gcZd8PCjfTo16Dm6S9NmbSUzectyBJlWxx9VYgf2uV8WtznnFWG7oQz6obOqUOkme5tf X-Received: by 10.107.168.21 with SMTP id r21mr2051437ioe.45.1490955375430; Fri, 31 Mar 2017 03:16:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 31 Mar 2017 03:16:15 -0700 (PDT) In-Reply-To: <6d0f6a54-c893-00a9-2181-29a5d766f4a3@redhat.com> References: <20170329175039.29635-1-ard.biesheuvel@linaro.org> <18095962-76eb-7337-969d-4f6080dff4d7@redhat.com> <41a87740-7634-bfde-d2fb-3767a5c33140@redhat.com> <6d0f6a54-c893-00a9-2181-29a5d766f4a3@redhat.com> From: Ard Biesheuvel Date: Fri, 31 Mar 2017 11:16:15 +0100 Message-ID: To: Laszlo Ersek Cc: Marc Zyngier , "edk2-devel@lists.01.org" , Mark Rutland , Drew Jones , Jon Masters Subject: Re: [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override 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: Fri, 31 Mar 2017 10:16:16 -0000 Content-Type: text/plain; charset=UTF-8 On 31 March 2017 at 10:59, Laszlo Ersek wrote: > On 03/31/17 11:20, Marc Zyngier wrote: >> On 30/03/17 09:40, Ard Biesheuvel wrote: >>> On 29 March 2017 at 20:35, Laszlo Ersek wrote: >>>> On 03/29/17 21:10, Ard Biesheuvel wrote: >>> [...] >>>>> >>>>> How on earth is having two ways to disable ACPI rather than one going >>>>> to cause fragmentation? Unlike v1, this patch does not allow you to >>>>> expose both DT and ACPI tables at the same time. >>>> >>>> Oopsie daisy. You actually updated the commit message too. (I have now >>>> formally diffed v1 vs. v2, including commit msg -- I generally do that >>>> when reviewing incremental versions of patches, but it has been a very >>>> long day, and I failed to get my mind off the track set up by v1). I got >>>> really no good explanation for missing the fundamental logic change >>>> between v1 and v2. As you say, version 2 preserves the mutual exclusion >>>> between DT and ACPI that I'm so annoyingly obsessed about. Thank you for >>>> the update. >>>> >>>> Reviewed-by: Laszlo Ersek >>>> >>> >>> Thanks Laszlo. I am glad we have a solution we can both live with. >>> >>> I will wait for Marc to confirm that this works as expected for him. >> >> [ This email won't make it on the edk2 list because it filters out >> non-subscribers. Boo! ] > > I fully agree: boo. I've raised this several times in the past, because > it is rude to people with occasional interest, and diverges sharply from > the custom on most other open source development lists. But, I had no > success in changing the policy. I really don't understand what other > subscribers are worried about. Spam is generally not a problem. > >> This patch does a very good job at restoring a functionality I'd have >> otherwise lost. So for the record: >> >> Tested-by: Marc Zyngier >> Acked-by: Marc Zyngier >> >> My only comment is that it that the enabling method is slightly cryptic, >> and suffers from a lack of documentation. For example, it doesn't seem >> to appear in Build/ArmVirtQemu-AARCH64/RELEASE_GCC5/FV/Guid.xref, which >> is where I'd have expected to find it. > > That happens because BaseTools approaches the Guid.xref file generation > from the direction of modules -- it goes over all modules and checks > what plain GUIDs, protocol GUIDs, and PPI GUIDs it uses. > > However, in this case, gArmVirtVariableGuid is never directly used in > PlatformHasAcpiDtDxe -- the driver never directly reads the UEFI > variable in question, so it doesn't need the GUID for naming the > variable's namespace. Instead, the connection to UEFI variables is made > in the "ArmVirtQemu.dsc" platform description file; that's where the > GUID is also named. > > [PcdsDynamicHii] > gArmVirtTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gArmVirtVariableGuid|0x0|FALSE|NV,BS > > I guess we could file a BaseTools enhancement request to print out the > variable namespace GUIDs used with dynamic HII PCDs. Ard, what do you think? > I guess this is an omission, but I have never used Guid.xref in my life so I have no strong feelings as to how this should be fixed.