This repository has been archived by the owner on May 12, 2021. It is now read-only.
Kernel: add config fragment support #646
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
devimc
pushed a commit
to devimc/kata-runtime
that referenced
this pull request
Jul 19, 2019
Depends-on: github.com/kata-containers/packaging#646 Fixes: #1234567 Signed-off-by: Julio Montes <julio.montes@intel.com>
jodh-intel
reviewed
Jul 22, 2019
| local cmdpath="${kernel_path}/scripts/kconfig/merge_config.sh" | ||
| local config_path="${arch_path}/.config" | ||
|
|
||
| local arch_configs="$(ls ${arch_path}/*.conf)" |
There was a problem hiding this comment.
Do we need arch-specific kernel fragment config files for all the other (non-x86_64) architectures to ensure those kernel continue to build as they do today?
There was a problem hiding this comment.
The code is written so if it does not find arch specific fragments it reverts to using the non-fragment configs. Thus, we can add arches as and when they have their fragments ready, and not delay the merge of the framework and x86 fragments :-)
jodh-intel
approved these changes
Jul 22, 2019
|
/test |
1 similar comment
|
/test |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
devimc
force-pushed
the
topic/kernel/fragmentsSupport
branch
from
b686006
to
6bc311f
Compare
|
/test |
devimc
force-pushed
the
topic/kernel/fragmentsSupport
branch
from
6bc311f
to
42a3acb
Compare
|
/test |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
@egernst @grahamwhaley @ganeshmaharaj CI is happy, can we merge this? |
GabyCT
approved these changes
Jul 24, 2019
egernst
approved these changes
Jul 25, 2019
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Add the framework to build kernel config files from trees of kernel fragments. If no fragment directory is found for the requested kernel version and architecture then revert to looking for a whole prebuilt kernel config file instead. Fixes: kata-containers#234 Signed-off-by: Graham Whaley <graham.whaley@intel.com>
Embellish the README a bit, and add some details about the new fragment method. Signed-off-by: Graham Whaley <graham.whaley@intel.com>
Add the base common fragments and x86_64 specific fragments for the 4.19.x kernel. Signed-off-by: Graham Whaley <graham.whaley@intel.com>
Now we are using the fragments, drop the x86_64 4.19 config file so we default to fragment mode. Signed-off-by: Graham Whaley <graham.whaley@intel.com>
bump kernel version to 46 Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
force-pushed
the
topic/kernel/fragmentsSupport
branch
from
42a3acb
to
9b0fdf2
Compare
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/test |
use `merge_config.sh` script to generate the final `.config` file if the
`${arch}_kata_kvm_*` file doesn't exist.
Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
force-pushed
the
topic/kernel/fragmentsSupport
branch
from
9b0fdf2
to
9e8cd7d
Compare
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/test |
|
All green - merged :) , kudos @devimc |
devimc
pushed a commit
to devimc/kata-agent
that referenced
this pull request
Jul 30, 2019
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
pushed a commit
to devimc/kata-agent
that referenced
this pull request
Jul 31, 2019
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
pushed a commit
to devimc/kata-agent
that referenced
this pull request
Jul 31, 2019
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. The list of kernel modules and their options are set through gRPC when the sandbox is created. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
pushed a commit
to devimc/kata-agent
that referenced
this pull request
Aug 1, 2019
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. The list of kernel modules and their parameters are set through gRPC when the sandbox is created. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
original pull request #314