Memory hotplugging issues on x86 kernel with CONFIG_ARCH_MEMORY_PROBE=y

[rhafer]

Description of problem

While testing kata-containers with a (openSUSE) distribution kernel I noticed that it fails to launch containers when using a custom memory limit (e.g. docker run -m 2G). Further debugging showed that this is related to the fact that the kernel is build with CONFIG_ARCH_MEMORY_PROBE=y. Which causes /sys/devices/system/memory/probe to be present on the system. On x86 however usually ACPI is reponsible for notifying the system of added hotplugged memory. So even when /sys/devices/system/memory/probe is present there should be a need to use it in general (AFAIK it's mostly there for debugging/testing on x86). The kata-agent however is using the interface unconditionally which is causing issues when ACPI is already taking care of the added memory (writes to /sys/devices/system/memory/probe for already added ranges error out with EEXIST, which causes the hotplugging code in agent to error out and guest VM to be deleted again).

Expected result

docker run -m 2G succeeds to launch a container, even when the guest kernel is build with CONFIG_ARCH_MEMORY_PROBE=y on x86

Actual result

The above command fails with:

rpc error: code = Unknown desc = write /sys/devices/system/memory/probe: file exists: unknown

[rhafer]

I am currently working on a patch to address the issue.

[grahamwhaley]

thanks @rhafer /cc @jcvenegas who worked on the memory hotplug stuff irc, and @devimc who has done a bunch around the ACPI hotplug (mostly pci/devices I think).

[rhafer]

The /sys/devices/system/memory/probe code in the agent was introduced for memory hotplugging support on ARM it seems (see #442). However on that architecture is even requires a patched kernel.

Seems a possible fix to make it work on all archs is to check /sys/firmware/acpi/hotplug/memory/enabled if that is present and contains 1 the writes to the probe file can be skipped.

[grahamwhaley]

/cc @Pennyzct for the ARM side input :-)