On Wed, 3 Apr 2019 16:25:49 +0000 Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> wrote:
> Hi Laszlo, > > > -----Original Message----- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: 03 April 2019 14:29 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com>; > > Igor Mammedov <imamm...@redhat.com> > > Cc: Auger Eric <eric.au...@redhat.com>; Ard Biesheuvel > > <ard.biesheu...@linaro.org>; peter.mayd...@linaro.org; > > sa...@linux.intel.com; qemu-devel@nongnu.org; Linuxarm > > <linux...@huawei.com>; shannon.zha...@gmail.com; > > qemu-...@nongnu.org; xuwei (O) <xuw...@huawei.com>; > > sebastien.bo...@intel.com; Leif Lindholm <leif.lindh...@arm.com> > > Subject: Re: [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in > > feature "fdt" > > > > On 04/03/19 14:10, Shameerali Kolothum Thodi wrote: > > > > >>>>> So, the condition for hiding the hotpluggable memory nodes in question > > >>>>> from the DT is: > > >>>> > > >>>>> > > >>>>> (aarch64 && firmware_loaded && acpi_enabled) > > > > >>> While UEFI has bindings for both 32-bit and 64-bit ARM, ACPI has a > > >>> 64-bit-only binding for ARM. (And you can have UEFI without ACPI, but > > >>> not the reverse, on ARM.) So if you run the 32-bit build of the > > >>> ArmVirtQemu firmware, you get no ACPI at all; all you can rely on with > > >>> the OS is the DT. > > > > > > Just to confirm, does that mean with 32-bit build of the UEFI, the OS > > > cannot > > > boot with ACPI and uses DT only. > > > > Indeed. > > > > > So, > > > > > > If ((aarch64 && firmware_loaded && acpi_enabled) { > > > Hide_hotpluggable_memory_nodes() > > > } else { > > > Add_ hotpluggable_memory_nodes() > > > } > > > > > > should work for all cases? > > > > Yes. > > > > Here's what happens when any one of the subconditions evaluates to false: > > > > - ARM32 has no ACPI bindings, so the guest kernel can only use DT. > > > > - On AARCH64, if you don't "load the firmware" (= don't use UEFI), then > > there won't be an ACPI entry point for the OS to locate (the RSD PTR > > is defined by the ACPI spec in UEFI terms, for AARCH64). So the guest > > kernel can only use DT. > > > > - When on AARCH64 and using UEFI, but asking QEMU not to generate ACPI > > content, the firmware will not install any ACPI tables, so the guest > > kernel can only use DT. > > > > Thanks. That makes it very clear. Much appreciated. > > > >>> This "bitness distinction" is implemented in the firmware already. If > > >>> you hid the memory nodes from the DT under the condition > > >>> > > >>> (!aarch64 && firmware_loaded && acpi_enabled) > > >>> > > >>> then the nodes would not be seen by the OS at all (because > > >>> "acpi_enabled" is irrelevant for the 32-bit build of ArmVirtQemu, and > > >>> all the OS can ever get is DT). > > >> > > >> It's getting tricky and I don't like a bit that we are trying to carter > > >> 64 bit only UEFI build (or any other build) on QEMU side. Also Peter has > > >> a valid about guessing on QEMU side (that's usually a source of problem > > >> in the future). > > > > > > If the above is correct(with 32-bit variant of UEFI, OS cannot have ACPI > > > boot), > > > then do we really have the issue of memory becoming non > > hot-un-unpluggable? > > > May be I am missing something. > > > > I think Igor and Peter dislike adding complex logic to QEMU that > > reflects the behavior of a specific firmware. AIUI their objection isn't > > that it wouldn't work, but that it's not the right thing to do, from a > > design perspective. > > Understood. Hope we can converge on something soon. Lets try adding a parameter to memory descriptors in DT that would mark them as hotpluggable. > Cheers, > Shameer
