Add unit test to function GetCPUVariantFromArch
Fix import issue on non-linux platforms
Fix some style issue
Signed-off-by: Tony Fang <nenghui.fang@gmail.com>
When images/containers in ARM arch were built/executed on x86 host,
getCPUVariant will fail as it tries to look for /proc/cpuinfo, whose
content is from the host. Adding a new method as fallback to check uname
machine when it happens.
Signed-off-by: Tony Fang <nenghui.fang@gmail.com>
This changes platforms.Parse to hit /proc to look up CPU info only when
it's needed, instead of in init(). This makes the package a bit easier
for other packages to consume, especially clients that don't call
platforms.Parse or need to lookup CPU info.
Signed-off-by: Jason Hall <jasonhall@redhat.com>
This isn't supported by *all* arm64 chips, but it is common enough that I think it's worth an explicit fallback. I think it will be more common for images to have arm64 support without arm support, but even if a user has an arm64 chip that does not support arm32, having it fail to run the arm32 image is an acceptable compromise (because it's non-trivial to detect arm32 support without running a binary, AFAIK).
Also, before this change the failure would've simply been "no such image" instead of "failed to run" so I think it's pretty reasonable to allow it to try the additional 32bit set of images just in case one of them actually does work (like it will on many popular chips like 64bit Raspberry Pis and AWS Graviton).
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled.
To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Don't rely on /proc/cpuinfo denoting a 64-bit ARMv8 processor if the
runtime detected GOARCH == arm. This allows aarch64 32-bit userspace
distros to run containers properly via a 32-bit runtime.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
This commit improves ARM platform matching in two instances:
* Some old kernels reported the CPU architecture of arm64 cpus as
Aarch64 [1].
* In cases where the user is running with armv8 cpu and kernel but amrhf
user land (so armhf containerd), a possibility given the compatibility
of armv8 with armv7.
[1] https://elixir.bootlin.com/linux/v3.14.29/source/arch/arm64/kernel/setup.c#L420
Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
ARM variant detection logic was authored originally with
POSIX OS in mind. This change leaves POSIX code path unaltered
and adds support to detect ARM variant on Windows by leveraging
runtime.goarch.
Signed-off-by: Jiri Appl <jiria@microsoft.com>
In the commit "26329b2b8d7fd4e290b2b0f0163547f2d79bb817",
dmcgowan/fix-pull-multi-arch, PR#1535. The containerd has enabled the pull
multi-arch image support. But the platform.variant field of OCI for ARM
hadn't been ready at that time, so all ARM images could not pull successfully.
"
docker.io/library/hello-world:latest:
resolved |++++++++++++++++++++++++++++++++++++++|
index-sha256:3644c0788e3d3823f9e97f757f01d2ddc6eb5458df9d801:
done |++++++++++++++++++++++++++++++++++++++|
elapsed: 5.1 s
total: 2.7 Ki (533.0 B/s)
unpacking sha256:3d3823f9e97f757f01d2ddc6eb5458df9d801...
ctr: : manifest not found: not found
"
In this patch we'll detect the ARM variants from /proc/cpuinfo. Because Linux
kernel has already detected the ABI, ISA and Features for us. We don't need to
parse them from registers again.
Change-Id: I479b34bf3f52df9f7a6b3c77718b7d316dbf7f69
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Penny Zheng <Penny.Zheng@arm.com>
