| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 25 May 2015 10:40:54 +0900 From: Masahiro Yamada <yamada.masahiro@...ionext.com> To: "Luis R. Rodriguez" <mcgrof@...e.com> Cc: "Luis R. Rodriguez" <mcgrof@...not-panic.com>, Michal Marek <mmarek@...e.cz>, david.vrabel@...rix.com, konrad.wilk@...cle.com, Ian Campbell <Ian.Campbell@...rix.com>, xen-devel@...ts.xenproject.org, josh@...htriplett.org, Borislav Petkov <bp@...e.de>, penberg@...nel.org, rientjes@...gle.com, rdunlap@...radead.org, Sasha Levin <levinsasha928@...il.com>, mtosatti@...hat.com, fengguang.wu@...el.com, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v6 2/2] kconfig: add xenconfig defconfig helper Hi Luis, 2015-05-22 3:47 GMT+09:00 Luis R. Rodriguez <mcgrof@...e.com>: > On Thu, May 21, 2015 at 11:49:17PM +0900, Masahiro Yamada wrote: >> Hi, >> >> I am not familiar with xen at all, just some comments >> from the build system side. >> >> >> >> 2015-05-21 3:53 GMT+09:00 Luis R. Rodriguez <mcgrof@...not-panic.com>: >> > From: "Luis R. Rodriguez" <mcgrof@...e.com> >> > >> > This lets you build a kernel which can support xen dom0 >> > or xen guests on i386, x86-64 and arm64 by just using: >> > >> > make xenconfig >> > >> > You can start from an allnoconfig and then switch to xenconfig. >> > This also splits out the options which are available currently >> > to be built with x86 and 'make ARCH=arm64' under a shared config. >> > >> > Technically xen supports a dom0 kernel and also a guest >> > kernel configuration but upon review with the xen team >> > since we don't have many dom0 options its best to just >> > combine these two into one. >> > >> > A few generic notes: we enable both of these: >> > >> > CONFIG_INET=y >> > CONFIG_BINFMT_ELF=y >> > >> > although technically not required given you likely will >> > end up with a pretty useless system otherwise. >> > >> > A few architectural differences worth noting: >> > >> > $ make allnoconfig; make xenconfig > /dev/null ; \ >> > grep XEN .config > 64-bit-config >> > $ make ARCH=i386 allnoconfig; make ARCH=i386 xenconfig > /dev/null; \ >> > grep XEN .config > 32-bit-config >> > $ make ARCH=arm64 allnoconfig; make ARCH=arm64 xenconfig > /dev/null; \ >> > grep XEN .config > arm64-config >> > >> > Since the options are already split up with a generic config and >> > architecture specific configs you anything on the x86 configs >> > are known to only work right now on x86. For instance arm64 doesn't >> > support MEMORY_HOTPLUG yet as such although we try to enabe it >> > generically arm64 doesn't have it yet, so we leave the xen >> > specific kconfig option XEN_BALLOON_MEMORY_HOTPLUG on x86's config >> > file to set expecations correctly. >> > >> > Then on x86 we have differences between i386 and x86-64. The difference >> > between 64-bit-config and 32-bit-config is you don't get XEN_MCE_LOG as >> > this is only supported on 64-bit. You also do not get on i386 >> > XEN_BALLOON_MEMORY_HOTPLUG, there does not seem to be any technical >> > reasons to not allow this but I gave up after a few attempts. >> > >> > Cc: Josh Triplett <josh@...htriplett.org> >> > Cc: Borislav Petkov <bp@...e.de> >> > Cc: Pekka Enberg <penberg@...nel.org> >> > Cc: David Rientjes <rientjes@...gle.com> >> > Cc: Michal Marek <mmarek@...e.cz> >> > Cc: Randy Dunlap <rdunlap@...radead.org> >> > Cc: penberg@...nel.org >> > Cc: levinsasha928@...il.com >> > Cc: mtosatti@...hat.com >> > Cc: fengguang.wu@...el.com >> > Cc: David Vrabel <david.vrabel@...rix.com> >> > Cc: Ian Campbell <Ian.Campbell@...rix.com> >> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> >> > Cc: xen-devel@...ts.xenproject.org >> > Acked-by: Stefano Stabellini <stefano.stabellini@...citrix.com> >> > Acked-by: Julien Grall <julien.grall@...aro.org> >> > Acked-by: Michal Marek <mmarek@...e.cz> >> > Acked-by: David Rientjes <rientjes@...gle.com> >> > Reviewed-by: Josh Triplett <josh@...htriplett.org> >> > Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com> >> > --- >> >> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile >> > index 6950032..f52abae 100644 >> > --- a/scripts/kconfig/Makefile >> > +++ b/scripts/kconfig/Makefile >> > @@ -115,6 +115,10 @@ PHONY += kvmconfig >> > kvmconfig: kvm_guest.config >> > @: >> > >> > +PHONY += xenconfig >> > +xenconfig: xen.config >> > + @: >> > + >> > PHONY += tinyconfig >> > tinyconfig: >> > $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config >> >> >> "make xenconfig" is equivalent to "make xen.config" >> and only saves one character. >> >> Now we have only three targets for mergeconfig (tiny, kvm, xen), >> so it is OK to add this as an alias. >> But if we have more such targets, we might have >> to consider to use generic targets (*.config) at some point. > > I'm frankly terrified of all these config target options growing more and > the possible large collateral of patches to Kconfig files in the future. Since > this is a small specialized group now, I think we should treat it as such but > I think what you say has good merit long run. > > For now I'm more of a fan we limit what we stuff in here and if this explodes > then only have new options use the subject.config target. Thoughts? Sounds good to me. >> I do not intend to block this. >> Just take my comment with a grain of salt.. >> >> >> > @@ -140,6 +144,7 @@ help: >> > @echo ' listnewconfig - List new options' >> > @echo ' olddefconfig - Same as silentoldconfig but sets new symbols to their default value' >> > @echo ' kvmconfig - Enable additional options for kvm guest kernel support' >> > + @echo ' xenconfig - Enable additional options for xen dom0 and guest kernel support' >> > @echo ' tinyconfig - Configure the tiniest possible kernel' >> > >> > # lxdialog stuff >> >> >> If kvmconfig and xenconfig are only available for x86, >> is it better to enclose those helps with >> ifeq ($(ARCH),x86) >> ... >> endif > > That's true if kvm was only for x86 but it is not, and likewise for xen. > OK, then. Thanks for explaining this. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists