Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

kernel: Add memory hotplug(add) support for arm64 #312

Merged
merged 2 commits into from
Jan 25, 2019

Conversation

jongwu
Copy link
Contributor

@jongwu jongwu commented Jan 18, 2019

As memory hotplug for arm64 by acpi is not ready on qemu, we choose
"probe" instead. You can refer to [1] to get more infomation about
"probe". The process of memory hotplug by "probe" in kata lies below:
firstly, add memory in qemu qmp; secondly, echo the start phyical address
of that memory to /sys/devices/system/memory/probe, which will be done
through kata-agent; thirdly, excute online op, then this newly added
memory is capable to be used.

All functions in this patch will be called after "echo" op. It can be
divided into two parts:
1. create page table for that memory;
2. add that memory to memblock.

In this patch, NUMA must be turned off for not all arm64 machine supports
NUMA.
As the newly added memory should be placed from 2T to 6T which is decided
in qemu and phyical address and virtual address will be one-one mapping
when create pgd for that memory, we must config ARM64_VA_BITS as 48.
Also some configs should be turned on, especially "ARCH_MEMORY_PROBE".

We have tested this patch integrated with another patch which performed
that echo op. It works well when using "-m" in command line when start a
kata-container on aarch64 machine.

This patch derived from Maciej Bielski. You can refer to [2] to get full
infomation about it.

[1] https://www.kernel.org/doc/Documentation/memory-hotplug.txt
[2] https://lkml.org/lkml/2017/11/23/183

@jon @liwei @jbryce @gnawux @Pennyzct

As memory hotplug for arm64 by acpi is not ready on qemu, we choose
"probe" instead. You can refer to [1] to get more infomation about
"probe". The process of memory hotplug by "probe" in kata lies below:
firstly, add memory in qemu qmp; secondly, echo the start phyical address
of that memory to /sys/devices/system/memory/probe, which will be done
through kata-agent; thirdly, excute online op, then this newly added
memory is capable to be used.

All functions in this patch will be called after "echo" op. It can be
divided into two parts:
1. create page table for that memory;
2. add that memory to memblock.

In this patch, NUMA must be turned off for not all arm64 machine supports
NUMA.
As the newly added memory should be placed from 2T to 6T which is decided
in qemu and phyical address and virtual address will be one-one mapping
when create pgd for that memory, we must config ARM64_VA_BITS as 48.
Also some configs should be turned on, especially "ARCH_MEMORY_PROBE".

We have tested this patch integrated with another patch which performed
that echo op. It works well when using "-m" in command line when start a
kata-container on aarch64 machine.

This patch derived from Maciej Bielski. You can refer to [2] to get full
infomation about it.

[1] https://www.kernel.org/doc/Documentation/memory-hotplug.txt
[2] https://lkml.org/lkml/2017/11/23/183

Fixes: kata-containers#309

Signed-off-by: Jianyong Wu  <[email protected]>
Signed-off-by: Jia He <[email protected]>
Signed-off-by: Penny Zheng <[email protected]>
Copy link

@devimc devimc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @jongwu
lgtm

@jongwu
Copy link
Contributor Author

jongwu commented Jan 22, 2019

@grahamwhaley @jodh-intel any comments?

Copy link
Contributor

@jodh-intel jodh-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jongwu.

lgtm

@@ -9,7 +9,7 @@ CONFIG_MMU=y
CONFIG_ARM64_PAGE_SHIFT=12
CONFIG_ARM64_CONT_SHIFT=4
CONFIG_ARCH_MMAP_RND_BITS_MIN=18
CONFIG_ARCH_MMAP_RND_BITS_MAX=24
CONFIG_ARCH_MMAP_RND_BITS_MAX=33
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @grahamwhaley - x86_64 specifies 32 here whilst ppc64 specifies 33. Should we do 34? 😆

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh heh - this is probably quite arch specific, to do with MMU mmaps - so, expect them to maybe be different.
For ref, the x86 kernel config arch files have some defaults if not set (different for 32 and 64 bit - I'll just list the 64bit ones):

  • MAX 32
  • MIN 28

Copy link
Contributor

@grahamwhaley grahamwhaley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
nice :-)

@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.14.72 Kernel Configuration
# Linux/arm64 4.14.67 Kernel Configuration
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

slightly odd having the kernel version go down - I guess you are testing on a kernel not quite as recent as the original - I'll let you decide if that is right or not ;-)

Copy link
Contributor Author

@jongwu jongwu Jan 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@grahamwhaley we change it from 72 to 67 according to the kernel version setting in runtime/versions.yaml.
as kernel version in https://cdn.kernel.org/pub/linux/kernel/v4.x/ is upper than 67, maybe we can upgrade it in runtime/version.yaml.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we have 67 in our versions.yaml file. Should be in sync.

@grahamwhaley
Copy link
Contributor

even though afaik this will not get tested on the ARM CI - I'm going to fire the tests on it anyway to make it clearer this is probably mergeable...
/test

@jodh-intel
Copy link
Contributor

@grahamwhaley - any update on that ARM CI run?

@grahamwhaley
Copy link
Contributor

As noted, the ARM CI is not enabled for this repo. I believe ARM CI is only enabled for the proxy repo - I'll open a different Issue to discuss enabling that further...
I ran the tests, not expecting anything to fail here - but, we got an odd 16.04 failure. @chavafg - look familiar at all?

HEAD is now at fa540c8... Merge pull request #1913 from runcom/fix-devmapper-112
/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kata-containers/tests
/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kubernetes-sigs/cri-o/test /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kata-containers/tests
Ensure crio service is stopped before running the tests
Ensure docker service is stopped before running the tests
time="2019-01-22T18:21:56Z" level=error msg="error copying docker://quay.io/crio/redis:alpine to dir:/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kubernetes-sigs/cri-o/.artifacts/redis-image: Error writing blob: read tcp 10.0.0.8:55872->52.84.90.103:443: read: connection reset by peer" 
Error pulling quay.io/crio/redis
Makefile:55: recipe for target 'crio' failed
make[2]: *** [crio] Error 1
make[2]: Leaving directory '/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kata-containers/tests'
Error:
line: 98
Last saved output:
INFO: Clone config and patches
INFO: Config version: 23
INFO: Kernel version: 4.14.67
make[2]: Entering directory '/tmp/build-kernel-tmp.8HS0IA5uOZ/kata-linux-4.14.67-23'
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  DESCEND  objtool
  CHK     include/generated/utsrelease.h
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  Building modules, stage 2.
  MODPOST 0 modules
  DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready  (#1)
make[2]: Leaving directory '/tmp/build-kernel-tmp.8HS0IA5uOZ/kata-linux-4.14.67-23'
INFO: Clone config and patches
lrwxrwxrwx 1 ubuntu ubuntu 18 Jan 22 17:58 /tmp/build-kernel-tmp.8HS0IA5uOZ/kernel-install-path/usr/share/kata-containers/vmlinux.container -> vmlinux-4.14.67-23
lrwxrwxrwx 1 ubuntu ubuntu 18 Jan 22 17:58 /tmp/build-kernel-tmp.8HS0IA5uOZ/kernel-install-path/usr/share/kata-containers/vmlinuz.container -> vmlinuz-4.14.67-23
/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kata-containers/packaging/.ci/../Makefile:38: recipe for target 'test-build-kernel' failed
make[1]: *** [test-build-kernel] Error 2
make[1]: Leaving directory '/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kata-containers/packaging'
Makefile:24: recipe for target 'test' failed
make: *** [test] Error 2
Build step 'Execute shell' marked build as failure

@chavafg
Copy link
Contributor

chavafg commented Jan 24, 2019

Seems like a network issue:

time="2019-01-22T18:21:56Z" level=error msg="error copying docker://quay.io/crio/redis:alpine to dir:/tmp/jenkins/workspace/kata-containers-packaging-ubuntu-16-04-PR/go/src/github.com/kubernetes-sigs/cri-o/.artifacts/redis-image: Error writing blob: read tcp 10.0.0.8:55872->52.84.90.103:443: read: connection reset by peer" 

Sending rebuild

@amshinde
Copy link
Member

Merging this, as CI has passed now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants