On Wed, Sep 27, 2017 at 10:47 PM, ChenQi <[email protected]> wrote: > On 09/27/2017 08:43 PM, Bruce Ashfield wrote: > > > > On Tue, Sep 26, 2017 at 4:57 PM, Christopher Clark > <[email protected]> wrote: >> >> On Mon, Sep 25, 2017 at 8:31 PM, Chen Qi <[email protected]> wrote: >> > Make these bbappend files to take effect only when DISTRO_FEATURES >> > contain 'virtualization'. Otherwise, we would meet failure failure >> > at system booting up qemux86. Related logs are as below. >> > >> > systemd-modules-load[113]: Failed to insert 'kvm_amd': Operation not >> > supported >> > systemd-modules-load[113]: Failed to insert 'kvm_intel': Operation not >> > supported >> > >> > Signed-off-by: Chen Qi <[email protected]> >> ... >> > diff --git a/recipes-kernel/linux/linux-yocto_virtualization.inc >> > b/recipes-kernel/linux/linux-yocto_virtualization.inc >> > new file mode 100644 >> > index 0000000..8b296d7 >> > --- /dev/null >> > +++ b/recipes-kernel/linux/linux-yocto_virtualization.inc >> > @@ -0,0 +1,20 @@ >> > +FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:" >> > + >> > +SRC_URI += "file://xt-checksum.scc \ >> > + file://ebtables.scc \ >> > + file://vswitch.scc \ >> > + file://lxc.scc \ >> > + file://docker.scc \ >> > + " >> > +KERNEL_FEATURES_append = " features/kvm/qemu-kvm-enable.scc" >> > + >> > +KERNEL_MODULE_AUTOLOAD += "openvswitch" >> > +KERNEL_MODULE_AUTOLOAD += "kvm" >> > +KERNEL_MODULE_AUTOLOAD += "kvm-amd" >> > +KERNEL_MODULE_AUTOLOAD += "kvm-intel" >> > + >> > +# aufs kernel support required for xen-image-minimal >> > +KERNEL_FEATURES_append += "${@bb.utils.contains('DISTRO_FEATURES', >> > 'aufs', ' features/aufs/aufs-enable.scc', '', d)}" >> > + >> > +# xen kernel support >> > +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' >> > file://xen.scc', '', d)}" >> > -- >> > 2.11.0 >> > >> > -- >> >> Suggestion for a preferred change: make the KVM features depend on >> DISTRO_FEATURES containing 'kvm', in the same way that the Xen >> features do for DISTRO_FEATURES containing 'xen'. >> >> Here's why: those KVM kernel modules are not of interest on Xen >> systems. With this change, you're removing the KVM features from the >> qemu build to solve your bug in hand, by making it conditional on >> 'virtualization', but is still leaves them present when only Xen is >> needed. >> >> With that change, I'm not sure whether a 'virtualization' disto >> feature is immediately useful. It could make sense for features that >> are hypervisor-agnostic but I don't have an immediate example to point >> to. > > > I like the suggestion as well. I'd like to future proof this a bit, and we > should keep the > virtualization feature around, but make the KVM features depend on kvm in > the > DISTRO_FEATURES. Less churn on distro flags is a good thing. > > Chen Qi, can you rework the check and warning message to reflect that 'kvm' > is the distro feature to set ? > > Bruce > > > Hi Bruce and Christopher, > > The status of 'kvm' in yocto (in specific, oe-core layer) is a little > different from that of 'xen'. > > 'xen' has been accepted as a distro feature, and the qemu recipe deals with > it like below. > meta/recipes-devtools/qemu/qemu.inc: > ${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \ > meta/recipes-devtools/qemu/qemu.inc:PACKAGECONFIG[xen] = > "--enable-xen,--disable-xen,xen,xen-libxenstore xen-libxenctrl > xen-libxenguest" > > However, for 'kvm', things are different. > It's enabled by default for the qemu (native, nativesdk and target) like > below. > PACKAGECONFIG ??= " \ > fdt sdl \ > fdt sdl kvm \ > ${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \ > " > PACKAGECONFIG_class-native ??= "fdt alsa kvm" > PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm" > PACKAGECONFIG[kvm] = "--enable-kvm,--disable-kvm" > To make things more complicated, our runqemu script, and the related oeqa > parts also deal with the 'kvm' parameter. > > When talking about 'kvm' above, I'm talking about it from the view of > treating 'kvm' as a distro feature. I know that enabling kvm for qemu and > enabling kvm related configs for kernel are two different things, although > they are somewhat related. > > Given the above situation, I'd like to suggest we don't deal with 'kvm' in > meta-virtualization for now. > I'll find time to see if we can make 'kvm' as a distro feature in oe-core. > And we deal with 'kvm' in this layer after that.
I'm actually not concerned about the oe-core part for now, getting this name into meta-virt correctly .. the first time .. is my concern. I don't want to only use 'virtualization' now, and then switch it later to match a new (more widely used) KVM distro feature. I had forgotten about the xen distro feature, and now that it has been pointed out, calling this 'virtualization' while it only impacts KVM build options to the kernel, doesn't make sense. So at a minimum, the kernel module autoload of kvm* should look for a kvm distro feature, but having the .inc included via the general 'virtualization' distro feature is still fine. Within the .inc, we have the xen and kvm differences .. which is fine. Bruce > > Best Regards, > Chen Qi > > > >> >> >> Christopher >> -- >> _______________________________________________ >> meta-virtualization mailing list >> [email protected] >> https://lists.yoctoproject.org/listinfo/meta-virtualization > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at > its end" > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
