From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web11.13877.1593006538212822059 for ; Wed, 24 Jun 2020 06:48:58 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 034A21F1; Wed, 24 Jun 2020 06:48:57 -0700 (PDT) Received: from [192.168.1.69] (unknown [10.37.8.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6AD3B3F6CF; Wed, 24 Jun 2020 06:48:49 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg/NorFlashQemuLib: disable NOR flash DT nodes upon discovery To: Andrew Jones , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Cc: devel@edk2.groups.io, lersek@redhat.com, Eric Auger References: <20200623175700.1564281-1-ard.biesheuvel@arm.com> <85a63fc4-f3d1-1e17-bf1d-dace59bb02a8@arm.com> <2a43b904-5172-0fb3-6d40-e1fd3b652fe7@redhat.com> <20200624134154.isbcqvscs7eidbd4@kamzik.brq.redhat.com> From: "Ard Biesheuvel" Message-ID: Date: Wed, 24 Jun 2020 15:48:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200624134154.isbcqvscs7eidbd4@kamzik.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/24/20 3:41 PM, Andrew Jones wrote: > On Wed, Jun 24, 2020 at 03:02:49PM +0200, Philippe Mathieu-Daud=C3=83=C2= =A9 wrote: >> On 6/24/20 1:43 PM, Ard Biesheuvel wrote: ... >>> I wasn't aware that we even expose the flash in the DSDT. In any case= , >>> no driver exists in Linux today that claims the LNRO0015 _HID, and so= I >>> agree we should simply remove it entirely. >>> >>> However, I am no longer able to contribute to QEMU, so I was hoping y= ou >>> or Phil could take the action? >> >> I try to stay as far as possible from ACPI, but here it seems >> fair I assign myself to this (except if Drew/Eric prefer to >> do it, of course!). >=20 > I don't mind doing it. IIUC, all we need to do is remove the flash devi= ce > from the DSDT to "hide" it from the guest. Of course we'll need some > compat code too in order to only do this for machine types 5.1 and late= r, > and that means that running guest kernels which want to bind the flash = on > 5.0 and older machine types will still have the problem. >=20 Do you think that is really necessary? LNRO0015 never had a driver in=20 Linux to begin with, and I doubt other ACPI capable arm64 OSes would be=20 any different. > Also, it seems a bit odd to hide hardware from the guest OS. Wouldn't i= t > be better to somehow flag that the hardare may be in use by firmware, > and therefore is only safe to use if runtime services are not used? I'm > not sure ACPI supports that for table entries like these, but maybe som= e > _STA value indicates something like it. I'll take a look at the spec. >=20 We could do either, but a _STA indicating that the device is not present=20 or not ready amounts to the same afaik. Ultimately, the OS could still=20 access the physical range if it wanted to (e.g., via /dev/mem), so not=20 exposing it in the first place seems more robust to me.