Re: [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt"

[Shameerali Kolothum Thodi]

Hi Laszlo,

> -----Original Message-----
> From: Laszlo Ersek [mailto:address@hidden
> Sent: 03 April 2019 14:29
> To: Shameerali Kolothum Thodi <address@hidden>;
> Igor Mammedov <address@hidden>
> Cc: Auger Eric <address@hidden>; Ard Biesheuvel
> <address@hidden>; address@hidden;
> address@hidden; address@hidden; Linuxarm
> <address@hidden>; address@hidden;
> address@hidden; xuwei (O) <address@hidden>;
> address@hidden; Leif Lindholm <address@hidden>
> 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.

Cheers,
Shameer