From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.14958.1593009446221934726 for ; Wed, 24 Jun 2020 07:37:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I+czCOLy; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: drjones@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593009445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BF5Uop5FrGXdMlF6N+/6fpG1d5YoLVQCNSn5PgAvEc8=; b=I+czCOLy1yO8KAaMtigCLMn0pX7g4ECvTwP7nzpmexH5l9GylNcWj4FdRGHwOoj0rqhHwb RZ+L/JgAH7qy9g+WDRtRArX8tXMGvQwHSuhfrJ1JNSw+dNnh9NFb+UCyaa3R7uKNE8GM7F E6xTZck2YNmrHnEfjDIwYGwmqR90XP4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-316-WUJ4xKyKMNGqZ4MW07hM_A-1; Wed, 24 Jun 2020 10:37:23 -0400 X-MC-Unique: WUJ4xKyKMNGqZ4MW07hM_A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D70118A8221; Wed, 24 Jun 2020 14:37:22 +0000 (UTC) Received: from kamzik.brq.redhat.com (unknown [10.40.194.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C60155BACA; Wed, 24 Jun 2020 14:37:13 +0000 (UTC) Date: Wed, 24 Jun 2020 16:37:09 +0200 From: Andrew Jones To: Ard Biesheuvel Cc: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , devel@edk2.groups.io, lersek@redhat.com, Eric Auger Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg/NorFlashQemuLib: disable NOR flash DT nodes upon discovery Message-ID: <20200624143709.odjhl5xc7ehxe2xl@kamzik.brq.redhat.com> 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> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline On Wed, Jun 24, 2020 at 03:48:46PM +0200, Ard Biesheuvel wrote: > On 6/24/20 3:41 PM, Andrew Jones wrote: > > On Wed, Jun 24, 2020 at 03:02:49PM +0200, Philippe Mathieu-Daudé 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 you > > > > 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!). > > > > I don't mind doing it. IIUC, all we need to do is remove the flash device > > 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 later, > > 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. > > > > Do you think that is really necessary? LNRO0015 never had a driver in Linux > to begin with, and I doubt other ACPI capable arm64 OSes would be any > different. I'd rather not add/remove hardware in older machine types. While it's unlikely anybody would notice, we can't be sure that there's nothing out there which would break. > > > Also, it seems a bit odd to hide hardware from the guest OS. Wouldn't it > > 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 some > > _STA value indicates something like it. I'll take a look at the spec. > > > > We could do either, but a _STA indicating that the device is not present or > not ready amounts to the same afaik. Ultimately, the OS could still access > the physical range if it wanted to (e.g., via /dev/mem), so not exposing it > in the first place seems more robust to me. > If there's no _STA state that says the device is here and works, but it's not available, then I agree removing it is the same. And, thinking about it some more, this flash device is really only for our host-controlled firmware. Since we don't give the guest any control over the firmware, then the device the firmware lives on should probably not even exist as far as the guest is concerned. Thanks, drew