[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt" |
Date: |
Mon, 8 Apr 2019 10:11:32 +0200 |
On Wed, 3 Apr 2019 16:25:49 +0000
Shameerali Kolothum Thodi <address@hidden> wrote:
> 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.
Lets try adding a parameter to memory descriptors in DT that would mark
them as hotpluggable.
> Cheers,
> Shameer
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", (continued)
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Shameerali Kolothum Thodi, 2019/04/02
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Auger Eric, 2019/04/02
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Laszlo Ersek, 2019/04/02
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Auger Eric, 2019/04/02
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Igor Mammedov, 2019/04/03
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Shameerali Kolothum Thodi, 2019/04/03
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Laszlo Ersek, 2019/04/03
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Shameerali Kolothum Thodi, 2019/04/03
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt",
Igor Mammedov <=
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Shameerali Kolothum Thodi, 2019/04/09
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Laszlo Ersek, 2019/04/03
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Igor Mammedov, 2019/04/08
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt", Peter Maydell, 2019/04/02