RFC: linux-yocto: provide OpenXT Linux kernels using kernel-yocto and config fragments #1383
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
jandryuk
reviewed
Jan 6, 2021
| # | ||
| # I2C support | ||
| # | ||
| CONFIG_I2C=y |
There was a problem hiding this comment.
I've only skimmed. This is better than the full defconfigs we currently use, but I am a little surprised by how how many lines are required for all the fragments. Picking I2C as an example, this seems like something we shouldn't need to enable explicit. Looks like, CONFIG_I2C_I801=y would select I2C_SMBUS... I think that would indirectly turn I2C on?
I'm guessing you started from a full defconfig? I recently found out about make savedefconfig. That saves only the non-default values, so the full .config is created after running through make oldconfig. For NDVM, make savedefconfig creates a 200-something line defconfig. Making fragments out of that should be much smaller.
There was a problem hiding this comment.
Actually I used bitbake -c diffconfig quite a bit to try and get as close as possible to the original defconfigs in order to not introduce too many significant changes.
That specific line comes directly from the original file in yocto-kernel-cache.
I agree though, that would avoid keeping some configuration enabled should another configuration fragment disable one that would have selected it.
v2:
Note: There is a segfault triggered in QEMU in a stubdomain for HVM guests with graphical output (NDVM is fine). It seems this comes from the surfman integration. |
eric-ch
commented
Jan 20, 2021
| patch bridge-carrier-follow-prio0.patch | ||
|
|
||
| # Cmdline option to have the bridge pass copy of the skb and release the initial one. | ||
| ## TODO: determine if this is necessary (not enabled by default in any vm) |
There was a problem hiding this comment.
This is not set anywhere, it should be deprecated.
added 4 commits
June 22, 2021 15:20
Create kernel configuration fragment for common Xen configurations applied to kernels built to run in Xen VM. This should cover dom0, pv, pvh and hvm guests and most if not all paravirtualized backend/frontend modules. Signed-off-by: Eric Chanudet <[email protected]>
Define ktypes to handle configuration of different kinds of Xen guest kernels: dom0, pv, pvh, hvm. All inherit a common base to avoid redundancies. Signed-off-by: Eric Chanudet <[email protected]>
OpenXT relies on service VMs to isolate different components for each others. Define abstract ktypes with the minimal configuration to support the following use-cases: - stubdom - uivm - ndvm These can then be configured for a targeted BSP. Signed-off-by: Eric Chanudet <[email protected]>
With the exception of backports, most patche series are independent of each others with little to no risk of conflicts. Attempt to isolate each on per features/goal and provide a configuration fragment to add in KERNEL_FEATURES. Signed-off-by: Eric Chanudet <[email protected]>
v3:
I initially did the renaming of the machines/images (the kernels have to be named differently) to be able to build this side-by-side in a tree. It should be easy to switch entirely or revert just the renaming. What would be the preferred path here? |
jandryuk
reviewed
Jun 24, 2021
| @@ -31,7 +31,7 @@ fi | |||
|
|
|||
| TBOOT_COMMON_CMD="min_ram=0x2000000 loglvl=all serial=115200,8n1,0x3f8 logging=serial,memory" | |||
| XEN_COMMON_CMD="dom0_mem=min:768M,max:768M,768M mbi-video vga=current flask=enforcing loglvl=debug guest_loglvl=debug ucode=-2 smt=0 bootscrub=1 argo=yes,mac-permissive=1" | |||
| LINUX_COMMON_CMD="console=hvc0 root=/dev/mapper/xenclient-root ro boot=/dev/mapper/xenclient-boot swiotlb=16384 xen_pciback.passthrough=1 consoleblank=0 video.delay_init=1 vt.global_cursor_default=0 rootfstype=ext3 bootfstype=ext3" | |||
| LINUX_COMMON_CMD="console=hvc0 root=/dev/mapper/xenclient-root ro boot=/dev/mapper/xenclient-boot swiotlb=16384 xen_pciback.passthrough=1 consoleblank=0 video.delay_init=1 vt.global_cursor_default=0 rootfstype=ext3 bootfstype=ext3 i915.enable_psr=0" | |||
There was a problem hiding this comment.
vglass commit f3286fe0382c55a4f4f50ce972f98ef1c6e103af "Mark framebuffer dirty to update contents" makes this unneeded now?
v4:
|
v4:
|
added 11 commits
July 16, 2021 16:32
The upstream provided generic common-pc/intel-x86 configuration
fragments tend to enable (builtin or as module) a lot more than what the
existing defconfigs for OpenXT do.
Add generic configuration fragments for:
- lvm/luks required components
- initrd, gz compressed (the others can be disabled)
- openxt-common.scc is only for convenience to include ubiquitous
features in current OpenXT service-VMs.
Arguably BSP:
- laptop-hp,
- laptop-dell,
- laptop-thinkpad, for various OEM specific configurations.
common-pc-drivers-reduced.scc tries to provide a finer
grained selection of modules than common-pc-drivers.scc provided
by yocto-kernel-cache.
common-pc-*{,-extended} add/define fragments for hardware OpenXT
supports but that is not provided by yocto-kernel-cache as configuration
fragment.
common-xen-vm provides configuration overrides to service-vms (currently
only disables unavailable components).
intel-x86-reduced is intel-x86.scc without components that are not
available in VMs that still have access to some hardware/emulated
things.
bsp/xen/intel-x86-64* gives a KMACHINE=intel-x86-64 base configuration
for each service VM. Additional features can be then configured at the
recipe level through KERNEL_FEATURES. A convenience intel-x86-64-vm.cfg
file factorizes commonalities for pv, pvh, hvm guests.
Signed-off-by: Eric Chanudet <[email protected]>
Add recipes to use linux-yocto kernel sources and yocto-kernel-cache configuration fragments for each OpenXT kernel configuration. Signed-off-by: Eric Chanudet <[email protected]>
The live installer for OpenXT should handle input/output hardware handled by dom0, ndvm and potentially other service VMs, but does not require Xen support. Add a livecd.scc ktype and BSP to compose a new configuration, intel-x86-64-standard provided by yocto-kernel-cache has a lot more feature than what dom0 and the service VMs will allow to handle. To support the BIOS legacy installation path, livecd-xen.scc is provided. This is because the legacy installer loads Xen and a dom0, but does not use or start any VM or any Xen tool. It also makes it easier to review compatibility between the installer and OpenXT. Signed-off-by: Eric Chanudet <[email protected]>
PREFERED_PROVIDER_virtual/kernel should be defined at the MACHINE level given each MACHINE has its own configuration. It is also hinted in the documentation: https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-filelayout-machine MACHINE=openxt-{dom0,uivm,ndvm,stubdom,live-installer} replace the former xenclient-* equivalent and set virtual/kernel preference. DISTRO=openxt-tip is openxt-main with no preference on the kernel. meta-virtualization has an annoying linux-%.bbappend, mask it. Remove MACHINE specific restrictions on initrdscripts. Signed-off-by: Eric Chanudet <[email protected]>
The system log isn't started yet and /dev/log does not obviously exist at that point (bootlogd is 07, right after mountall 06). Remove logger invocation. Signed-off-by: Eric Chanudet <[email protected]>
Changes in this patch are required to use differently named machines and images than then xenclient- prefixed ones. Signed-off-by: Eric Chanudet <[email protected]>
linux-yocto-openxt-stubdom includes modules, which are shipped in the initramfs. Load them using modprobe, it seems to be working just fine. Signed-off-by: Eric Chanudet <[email protected]>
i915 is builtin since the gem-foreign relies on internal kernel interfaces. Pass the parameter to disable PSR on the cmdline. Signed-off-by: Eric Chanudet <[email protected]>
Since the patch introducing this module is only applied in dom0, it is now builtin. Remove the runtime dependency. This out-of-tree module should be added to openxt-kmeta as a patch too in the end. Signed-off-by: Eric Chanudet <[email protected]>
vGlass can compose guests using radeon/nouveau drivers. Provide config fragments to include these in installer/dom0 where they can be used. Signed-off-by: Eric Chanudet <[email protected]>
Hosting txt_info.c as an out-of-tree module with its sources in the layer is not very elegant. The changes are small and configurable, and useful only to dom0. Make the out-of-tree module a patch against the kernel and create the associated configuration fragment so dom0's kernel can select it. Signed-off-by: Eric Chanudet <[email protected]>
v5:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This serie is an attempt to leverage
kernel-yocto.bbclassto provide useful kernel configurations for Xen/OpenXT like service VMs, in a way that would be easier to extend than maintaining an entire defconfig.openxt-kmetaprovides:To make experimentation easier and facilitate comparing the differences between kernel configurations using only one build tree, this change set defines a new set of MACHINE/images to build an OpenXT, the equivalences should be fairly straight forward (
s/xenclient-/openxt-,openxt-installer -> openxt-live-installer).a699b34 is still required since MACHINE names are referenced directly in various recipes.