From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.12885.1593003781420348621 for ; Wed, 24 Jun 2020 06:03:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bhG9RSrp; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: philmd@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593003780; 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:autocrypt:autocrypt; bh=+4PU53MUUbWZl3a9XvfV1e8VuIIhXHW8NCtetUN8Qn8=; b=bhG9RSrpv9N7ZVuCMscRquGHhjebwcCPZE5YrXNQS+xNknzJb27NDt6nleU/INxxAFcZ7F FJlm1ByD9GihQoSDfGEXoHspybZ+0gjP5/nLS9uwIHn4CNARh8U1LolGXm9/IPXLuHru1N sNUcBvZbxMoLpnUP9Ni/+jnbsLPZNAw= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-218-EPJumA1nOzuR0xvqtUeVCQ-1; Wed, 24 Jun 2020 09:02:52 -0400 X-MC-Unique: EPJumA1nOzuR0xvqtUeVCQ-1 Received: by mail-wm1-f70.google.com with SMTP id z11so2592164wmg.5 for ; Wed, 24 Jun 2020 06:02:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+4PU53MUUbWZl3a9XvfV1e8VuIIhXHW8NCtetUN8Qn8=; b=Y6Q16ukpVt2+WBJBtCXjtufzZ4u9BYL2drjNdida3/1U/OfvzbkD/6huyi+oMc5iVo PXVjNPmi8w8F7s+8pddcXC+sahneJOQXwGnmDUmDsX5n9d8WRsFIzw3okoHw64XKgTns FTje52xOyznJwW0I895AZcd7SljZsqjNOgFd83g3iTfzpI9CZbsj8Dxybpsup+hsPqEH XbrGt5WlbstOMbAtRIYZs7H0htZELArUcdF9F0BWF4ZKAhW0HY9z9C5MLGQlfJh0d5xV oxzmEs+eGQd1QUN29Shf4VCtcN/qPScb1YRvd6qohYThLJABA4uKahrhI8pWkz1IpcT5 hTaQ== X-Gm-Message-State: AOAM5326N3UqaCUVQ+645G5nQ48TO7E9XIquaNax09rRpVQtwbY7mAUP 5dGAKcJ4FSzmNk613zNx04Xap/kNxIZBl445zgeIkVP0iAS7+FKmHzsviu2IMoaenqn0EpzD/JJ iubgZO/PDEHC03g== X-Received: by 2002:a1c:3c1:: with SMTP id 184mr28633157wmd.40.1593003770764; Wed, 24 Jun 2020 06:02:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykIltT4GoIzK5boAxIBoIfQui7gmf46AqHKksw7pQUHGnBGARPB40QIEYTPS2rtqIXzcBJNw== X-Received: by 2002:a1c:3c1:: with SMTP id 184mr28633128wmd.40.1593003770456; Wed, 24 Jun 2020 06:02:50 -0700 (PDT) Return-Path: Received: from [192.168.1.40] (1.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.1]) by smtp.gmail.com with ESMTPSA id r8sm12509396wrp.40.2020.06.24.06.02.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 06:02:49 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg/NorFlashQemuLib: disable NOR flash DT nodes upon discovery To: Ard Biesheuvel , devel@edk2.groups.io, lersek@redhat.com Cc: Drew Jones , Eric Auger References: <20200623175700.1564281-1-ard.biesheuvel@arm.com> <85a63fc4-f3d1-1e17-bf1d-dace59bb02a8@arm.com> <2a43b904-5172-0fb3-6d40-e1fd3b652fe7@redhat.com> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: Date: Wed, 24 Jun 2020 15:02:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/24/20 1:43 PM, Ard Biesheuvel wrote: > On 6/24/20 1:20 PM, Laszlo Ersek via groups.io wrote: >> (CC Drew, Eric) >> >> On 06/24/20 09:19, Ard Biesheuvel wrote: >> >>> The arm64 defconfig was recently updated with MTD support, and so the >>> flash banks are now claimed by the CFI flash driver. I saw the same on >>> 32-bit ARM today, and I am not sure if it is a change there or whether >>> it was always like that (for multi_v7_defconfig) but there is no good >>> reason to keep supporting this. >> >> Can the same (problematic) kernel driver binding occur via the ACPI >> DSDT? >> >> In this fw patch we hide the flash chip(s) from the guest kernel via >> Device Tree only. >> >> There isn't much I guess we can (or should) do about ACPI in the >> firmware, but it would still be a conflict between the fw driver and the >> kernel driver -- we might have to address that in QEMU (hide the pflash >> in the ACPI generator when UEFI is used as guest firmware). >> >> IIRC, in QEMU, we use "arm_boot_info.firmware_loaded", from >> , to represent UEFI: >> >>>      /* Boot firmware has been loaded, typically at address 0, with >>> -bios or >>>       * -pflash. It also implies that fw_cfg_find() will succeed. >>>       */ >>>      bool firmware_loaded; >> >> And we already seem to have this exact kind of distinction in QEMU; see >> for example "hw/arm/virt.c": >> >>>      if (has_ged && aarch64 && firmware_loaded && >>> virt_is_acpi_enabled(vms)) { >>>          vms->acpi_dev = create_acpi_ged(vms); >>>      } else { >>>          create_gpio(vms); >>>      } >> >> coming from commit cff51ac978c4 ("hw/arm/virt: Enable device memory >> cold/hot plug with ACPI boot", 2019-10-05). >> >> And (same file): >> >>>          if (!vms->bootinfo.firmware_loaded || >>> !virt_is_acpi_enabled(vms)) { >>>              return HOTPLUG_HANDLER(machine); >>>          } >> >> coming from commit 70e89132c9e6 ("hw/arm/virt: Add the virtio-iommu >> device tree mappings", 2020-02-27). >> >> ... Ah, I think I've found it [hw/arm/virt-acpi-build.c]: >> >>> /* DSDT */ >>> static void >>> build_dsdt(GArray *table_data, BIOSLinker *linker, VirtMachineState >>> *vms) >>> { >>>      Aml *scope, *dsdt; >>>      MachineState *ms = MACHINE(vms); >>>      const MemMapEntry *memmap = vms->memmap; >>>      const int *irqmap = vms->irqmap; >>> >>>      dsdt = init_aml_allocator(); >>>      /* Reserve space for header */ >>>      acpi_data_push(dsdt->buf, sizeof(AcpiTableHeader)); >>> >>>      /* When booting the VM with UEFI, UEFI takes ownership of the >>> RTC hardware. >>>       * While UEFI can use libfdt to disable the RTC device node in >>> the DTB that >>>       * it passes to the OS, it cannot modify AML. Therefore, we >>> won't generate >>>       * the RTC ACPI device at all when using UEFI. >>>       */ >>>      scope = aml_scope("\\_SB"); >>>      acpi_dsdt_add_cpus(scope, vms->smp_cpus); >>>      acpi_dsdt_add_uart(scope, &memmap[VIRT_UART], >>>                         (irqmap[VIRT_UART] + ARM_SPI_BASE)); >>>      acpi_dsdt_add_flash(scope, &memmap[VIRT_FLASH]); >> >> The ACPI generator already takes the RTC into account; see QEMU commit >> 67736a25f865 ("ARM: virt: Don't generate RTC ACPI device when using >> UEFI", 2016-01-15). >> >> Should we do the same for the acpi_dsdt_add_flash() call, now? >> >> (This also suggests that my consideration of "firmware_loaded" above is >> irrelevant, if we end up modifying the build_dsdt() function -- on >> AARCH64, ACPI is only defined in UEFI terms (namely, as a UEFI system >> config table), so in this function, the presence of UEFI can be assumed >> "yes".) >> > > 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!). > > Thanks, > Ard. > > >