This script is responsible for generating a tarball with all the rust
vendored code that is needed for fully building kata-containers on a
disconnected environment.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
'make kata-tarball' sometimes fails early with:
cp: cannot create regular file '[...]/tools/packaging/kata-deploy/local-build/dockerbuild/install_yq.sh': File exists
This happens because all assets are built in parallel using the same
`kata-deploy-binaries-in-docker.sh` script, and thus all try to copy
the `install_yq.sh` script to the same location with the `cp` command.
This is a well known race condition that cannot be avoided without
serialization of `cp` invocations.
Move the copying of `install_yq.sh` to a separate script and ensure
it is called *before* parallel builds. Make the presence of the copy
a prerequisite for each sub-build so that they still can be triggered
individually. Update the GH release workflow to also call this script
before calling `kata-deploy-binaries-in-docker.sh`.
Fixes#3756
Signed-off-by: Greg Kurz <groug@kaod.org>
NO_TTY configured whether to add the -t option to docker run. It makes no
sense for the caller to configure this, since whether you need it depends
on the commands you're running. Since the point here is to run
non-interactive build scripts, we don't need -t, or -i either.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Greg Kurz <groug@kaod.org>
This directory consists entirely of files built during a make kata-tarball,
so it should not be committed to the tree. A symbolic link to this directory
might be created during 'make tarball', ignore it as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[greg: - rearranged the subject to make the subsystem checker happy
- also ignore the symbolic link created by
`kata-deploy-binaries-in-docker.sh`]
Signed-off-by: Greg Kurz <groug@kaod.org>
Right now it doesn't do much for us, as we're always building from a
specific version. However, this opens the possibility for us to add a
CI, similar to the one we have for CRI-O, for testing against each
cloud-hypervisor PR, on the cloud-hypervisor branch.
Fixes: #3908
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
bring Intel SGX support
Changes tha may impact in Kata Containers
Arm:
The 'virt' machine now supports an emulated ITS
The 'virt' machine now supports more than 123 CPUs in TCG emulation mode
The pl031 real-time clock device now supports sending RTC_CHANGE QMP events
PowerPC:
Improved POWER10 support for the 'powernv' machine
Initial support for POWER10 DD2.0 CPU added
Added support for FORM2 PAPR NUMA descriptions in the "pseries" machine
type
s390x:
Improved storage key emulation (e.g. fixed address handling, lazy
storage key enablement for TCG, ...)
New gen16 CPU features are now enabled automatically in the latest
machine type
KVM:
Support for SGX in the virtual machine, using the /dev/sgx_vepc device
on the host and the "memory-backend-epc" backend in QEMU.
New "hv-apicv" CPU property (aliased to "hv-avic") sets the
HV_DEPRECATING_AEOI_RECOMMENDED bit in CPUID[0x40000004].EAX.
virtio-mem:
QEMU now fully supports guest memory dumps with virtio-mem.
QEMU now cleanly supports precopy migration, postcopy migration and
background snapshots with virtio-mem.
fixes#3902
Signed-off-by: Julio Montes <julio.montes@intel.com>
As 2.4.0-rc0 has been released, let's switch the kata-deploy / kata-cleanup
tags back to "latest", and re-add the kata-deploy-stable and the
kata-cleanup-stable files.
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
kata-deploy files must be adapted to a new release. The cases where it
happens are when the release goes from -> to:
* main -> stable:
* kata-deploy-stable / kata-cleanup-stable: are removed
* stable -> stable:
* kata-deploy / kata-cleanup: bump the release to the new one.
There are no changes when doing an alpha release, as the files on the
"main" branch always point to the "latest" and "stable" tags.
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
During the release of 2.4.0-rc0 @egernst noticed an incositency in the
way we handle release tags, as release candidates are being taken as
"stable" releases, while both the kata-deploy tests and the release
action consider this as "latest".
Ideally we should have our own tag for "release candidate", but that's
something that could and should be discussed more extensively outside of
the scope of this quick fix.
For now, let's align the code generating the PR for bumping the release
with what we already do as part of the release action and kata-deploy
test, and tag "-rc" as latest, regardless of which branch it's coming
from.
Fixes: #3847
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Add a new entry of arm-kernel-experimental and let the kernel build
script support to build it.
Fixes: #3280
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
I'm sure that it is correct to remove CONFIG_ARM64_UAO and
CONFIG_MANDATORY_FILE_LOCKING and . Both are gone in 5.15. Maintain a
specific config files for a kernel version is a little ugly. If someone
needs them, shout at me.
Fixes: #3280
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
As the support for vcpu hotplug is on the road, I pick them up here as
experimental to let user try cpu hotplug and virtio-mem on arm64.
Fixes: #3280
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
With the ACPI PCI hotplug changes introduced in 2.3, QEMU >= 6.1 is required.
Remove unnecessary qemu version check in build script.
Fixes#3547
Signed-off-by: goodluckbot <tangbo_gl@hotmail.com>
4c164afbac renamed extra_build_args to
features, but did it only in one place, leading to:
```
21:15:28 /home/jenkins/workspace/kata-containers-2.0-ubuntu-ARM-PR/go/src/github.com/kata-containers/kata-containers/tools/packaging/static-build/cloud-hypervisor/build-static-clh.sh: line 55: features: unbound variable
21:15:29 make[1]: *** [tools/packaging/kata-deploy/local-build/Makefile:30: cloud-hypervisor-tarball-build] Error 1
```
Fixes: #3775
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's bump the Cloud Hypervisor version to 5343e09e7b8db, as that brings
a few fixes we're interested in, such as:
* hypervisor, vmm: Handle TDX hypercalls with INVALID_OPERAND
- https://github.com/cloud-hypervisor/cloud-hypervisor/pull/3723
- This is needed for the TDX support on the cloud hypervisor driver,
which is part of this very same series.
* openapi: Update the PciBdf types
- https://github.com/cloud-hypervisor/cloud-hypervisor/pull/3748
- This is needed due to a change in a DeviceNode field, which would
cause a marshalling / demarshalling error when running with a
version of cloud-hypervisor that includes the TDX fixes mentioned
above.
* scripts: dev_cli: Don't quote $features_build
* scripts: dev_cli: Add --features option
- https://github.com/cloud-hypervisor/cloud-hypervisor/pull/3773
- This is needed due to changes in the scripts used to build Cloud
Hypervisor, which are used as part of Kata Containers CIs and
github actions.
Due to this change, we're also adapting the build scripts as part
of this very same commit.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The kata-deploy Dockerfile is based on CentOS 7, which has no s390x
support. Add an `IMAGE` argument to specify the registry, which still
defaults to CentOS, but e.g. ClefOS can be selected instead.
Other x86_64 assumptions are also removed. Other general simplicifations
are made.
This does not address the more general issue of #3723 -- what we're
doing here does not seem to be working with systemd >= something between
235-237.
Fixes: #3722
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
When using kata-deploy, no `containerd-shim-kata-v2` binary is deployed,
but we do deploy a `kata` runtime class, which seems very much
incosistent.
As the default configuration for kata-containers points to QEMU, let's
also use kata with QEMU as the default shim-v2 binary.
Fixes: #3228, #3734
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The name of SYS_SUPPORTS_HUGETLBFS has been changed to
ARCH_SUPPORTS_HUGETLBFS which is being selected on default
by another kernel config.
More info- 855f9a8e87
Change applicable from v5.13.
Fixes: #3720
Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
`tools/packaging/scripts/apply_patches.sh` uses `git apply $patch`, but
this will not apply to subdirectories. If one wanted to apply with
`git apply`, they'd have to run it with `--directory=...`
_relative to the Git tree's root_ (absolute will not work!). I suggest
we just use `patch`, which will do what we expected `git apply` would
do.
`patch` is also added to build containers that require it.
Fixes: #3690
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
Let's take advantage of the fact that we've bumped to our kernel version
ot the 5.15 LTS and enable SGX by default, as it's present there.
Fixes: #3692
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Right now we're getting the info for the Cloud Hypervisor repo and
version, but we don't do anything with them, as those are not passed
down to the build script.
Morever, the build script itself gets the info from exactly the same
place when those are not passed, making those redundant.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Right now TDx support on Cloud Hypervisor is gated behind a "--features
tdx" flag. However, having TDx support enabled should not and does not
impact on the general usability of cloud-hypervisor.
As sooner than later we'll need kata-deploy binaries to be tested on a
CI that's TDx capable, for the confidential containers effort, let's
take the bullet and already enable it by default.
By the way, touching kata-deploy-binaries.sh as it's ensure the change
will be used in the following workflows:
* kata-deploy-push
* kata-deploy-test
* release
Fixes: #3688
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're downloading the released cloud-hypervisor binary from GitHub, but
we should also ensure we set the binary as executable.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's allow passing down a build flag to cargo, when building Cloud
Hypervisor.
By doing this we allow calling this script with:
```
extra_build_flags="--features tdx" ./build-static-clh.sh
```
Fixes: #3671
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The current code will always pull the release binaries in case the
version requested by Kata Containers matches with a released version.
This, however, has a limitation of preventing users / CIs to build
cloud-hypervisor from source for a reason or another, such as passing a
specific build flag to cloud-hypervisor.
This is a pre-req to solving
https://github.com/kata-containers/kata-containers/issues/3671.
While here, a small changes were needed in order to improve readability
and debugability of why we're building something from the sources rather
than simply downloading and using a pre-built binary.
Fixes: #3672
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Add support for building TDX kernel from github.com/intel/tdx
To build a guest kernel that supports Intel TDx run:
```
./build-kernel.sh -s -x tdx -d setup
./build-kernel.sh -s -x tdx -d install
```
fixes#3650
Signed-off-by: Julio Montes <julio.montes@intel.com>
When building a non-stable release, the tag is **always** "latest¨,
instead of the version. The same magic done for setting the correct
tags up should be done for replacing the tag on the kata-deploy and
kata-cleanup yaml files, as part of the kata-deploy test.
Fixes: #3559
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Now that kata-pkgsync has been removed, this PR removes the reference
in the documentation.
Fixes#3513
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
