[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/vi
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt |
Date: |
Wed, 8 May 2019 22:26:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 05/08/19 14:50, Robin Murphy wrote:
> Hi Shameer,
>
> On 08/05/2019 11:15, Shameerali Kolothum Thodi wrote:
>> Hi,
>>
>> This series here[0] attempts to add support for PCDIMM in QEMU for
>> ARM/Virt platform and has stumbled upon an issue as it is not clear(at
>> least
>> from Qemu/EDK2 point of view) how in physical world the hotpluggable
>> memory is handled by kernel.
>>
>> The proposed implementation in Qemu, builds the SRAT and DSDT parts
>> and uses GED device to trigger the hotplug. This works fine.
>>
>> But when we added the DT node corresponding to the PCDIMM(cold plug
>> scenario), we noticed that Guest kernel see this memory during early boot
>> even if we are booting with ACPI. Because of this, hotpluggable memory
>> may end up in zone normal and make it non-hot-un-pluggable even if Guest
>> boots with ACPI.
>>
>> Further discussions[1] revealed that, EDK2 UEFI has no means to
>> interpret the
>> ACPI content from Qemu(this is designed to do so) and uses DT info to
>> build the GetMemoryMap(). To solve this, introduced "hotpluggable"
>> property
>> to DT memory node(patches #7 & #8 from [0]) so that UEFI can
>> differentiate
>> the nodes and exclude the hotpluggable ones from GetMemoryMap().
>>
>> But then Laszlo rightly pointed out that in order to accommodate the
>> changes
>> into UEFI we need to know how exactly Linux expects/handles all the
>> hotpluggable memory scenarios. Please find the discussion here[2].
>>
>> For ease, I am just copying the relevant comment from Laszlo below,
>>
>> /******
>> "Given patches #7 and #8, as I understand them, the firmware cannot
>> distinguish
>> hotpluggable & present, from hotpluggable & absent. The firmware can
>> only
>> skip both hotpluggable cases. That's fine in that the firmware will
>> hog neither
>> type -- but is that OK for the OS as well, for both ACPI boot and DT
>> boot?
>>
>> Consider in particular the "hotpluggable & present, ACPI boot" case.
>> Assuming
>> we modify the firmware to skip "hotpluggable" altogether, the UEFI memmap
>> will not include the range despite it being present at boot.
>> Presumably, ACPI
>> will refer to the range somehow, however. Will that not confuse the OS?
>>
>> When Igor raised this earlier, I suggested that
>> hotpluggable-and-present should
>> be added by the firmware, but also allocated immediately, as
>> EfiBootServicesData
>> type memory. This will prevent other drivers in the firmware from
>> allocating AcpiNVS
>> or Reserved chunks from the same memory range, the UEFI memmap will
>> contain
>> the range as EfiBootServicesData, and then the OS can release that
>> allocation in
>> one go early during boot.
>>
>> But this really has to be clarified from the Linux kernel's
>> expectations. Please
>> formalize all of the following cases:
>>
>> OS boot (DT/ACPI) hotpluggable & ... GetMemoryMap() should report
>> as DT/ACPI should report as
>> ----------------- ------------------
>> ------------------------------- ------------------------
>> DT present ? ?
>> DT absent ? ?
>> ACPI present ? ?
>> ACPI absent ? ?
>>
>> Again, this table is dictated by Linux."
>>
>> ******/
>>
>> Could you please take a look at this and let us know what is expected
>> here from
>> a Linux kernel view point.
>
> For arm64, so far we've not even been considering DT-based hotplug - as
> far as I'm aware there would still be a big open question there around
> notification mechanisms and how to describe them. The DT stuff so far
> has come from the PowerPC folks, so it's probably worth seeing what
> their ideas are.
>
> ACPI-wise I've always assumed/hoped that hotplug-related things should
> be sufficiently well-specified in UEFI that "do whatever x86/IA-64 do"
> would be enough for us.
As far as I can see in UEFI v2.8 -- and I had checked the spec before
dumping the table with the many question marks on Shameer --, all the
hot-plug language in the spec refers to USB and PCI hot-plug in the
preboot environment. There is not a single word about hot-plug at OS
runtime (regarding any device or component type), nor about memory
hot-plug (at any time).
Looking to x86 appears valid -- so what does the Linux kernel expect on
that architecture, in the "ACPI" rows of the table?
Shameer: if you (Huawei) are represented on the USWG / ASWG, I suggest
re-raising the question on those lists too; at least the "ACPI" rows of
the table.
Thanks!
Laszlo
>
> Robin.
>
>> (Hi Laszlo/Igor/Eric, please feel free to add/change if I have missed
>> any valid
>> points above).
>>
>> Thanks,
>> Shameer
>> [0] https://patchwork.kernel.org/cover/10890919/
>> [1] https://patchwork.kernel.org/patch/10863299/
>> [2] https://patchwork.kernel.org/patch/10890937/
>>
>>
- [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Shameerali Kolothum Thodi, 2019/05/08
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Robin Murphy, 2019/05/08
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt,
Laszlo Ersek <=
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Igor Mammedov, 2019/05/09
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Laszlo Ersek, 2019/05/09
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Shameerali Kolothum Thodi, 2019/05/10
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Auger Eric, 2019/05/10
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Shameerali Kolothum Thodi, 2019/05/10
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Auger Eric, 2019/05/10
- Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Igor Mammedov, 2019/05/10
Re: [Qemu-devel] [Question] Memory hotplug clarification for Qemu ARM/virt, Laszlo Ersek, 2019/05/08