Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
- Original Message - On Fri, 6 Jan 2012, Andrew Jones wrote: XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. I think that it is less than that because backends are not tied to dom0 in any way, even though currently they cannot be compiled without XEN_DOM0. Running a network or block backend in domU is a well known configuration. Therefore the code compiled out only amounts to about 10K. diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 8795480..0725228 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN config XEN_BACKEND bool Backend driver support - depends on XEN_DOM0 default y + depends on XEN PCI_XEN SWIOTLB_XEN + depends on X86_LOCAL_APIC X86_IO_APIC ACPI PCI help Support for backend device drivers that provide I/O services to other virtual machines. I think we can trimmer the dependency list here: after all backends can be run in unpriviledged guests as well (see driver domains). So I think it should depend only on XEN. Hmm.. Actually, with dependency lists in mind, I think a really messed this patch up. I should have either had CONFIG_XEN inherit these deps, or I should have spread them around to be required at only the specific places they're needed, and then left the stub functions in. Neither of those options seems like a good idea to me. We either force all XEN guests to always have all the deps needed for an initial domain, which is exactly the opposite of the suggestion above (trimming XEN_BACKEND deps for driver domains), or we actually make the code messier and more complicated with more #ifdefs, which are now neatly packaged with XEN_DOM0. The driver domain concept may actually be the technical need for making XEN_DOM0 optional. If we want the ability to build a minimally configed XEN kernel to be used as a driver domain, then it doesn't seem like we'd want it to also be capable of running as an initial domain, or to be forced to have all the dependencies and code of an initial domain. With that in mind, I propose we go back to my initial patch, relax deps for XEN_BACKEND, and double check that each individual backend has the appropriate minimal deps. In general, it should be a goal to make sure most XEN options are menu selectable and that all dep lists are minimized in order to make sure driver domains can be built with minimal configs. Drew ___ Xen-devel mailing list xen-de...@lists.xensource.com http://lists.xensource.com/xen-devel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
- Original Message - Hi Andrew, On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote: - Original Message - On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote: PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but they don't use the xen frame buffer frontend. For this case it doesn't make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e. if you're using xenfb, then you'll want xenkbd. Switch the dependencies. You need to CC as well these people that have 'maintainer' field on them: konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f drivers/video/Kconfig Florian Tobias Schandinat florianschandi...@gmx.de (maintainer:FRAMEBUFFER LAYER) linux-fb...@vger.kernel.org (open list:FRAMEBUFFER LAYER) linux-ker...@vger.kernel.org (open list) konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f drivers/input/misc/Kconfig Dmitry Torokhov dmitry.torok...@gmail.com (maintainer:INPUT (KEYBOARD,...,commit_signer:9/16=56%) Samuel Ortiz sa...@linux.intel.com (commit_signer:3/16=19%) Anirudh Ghayal agha...@codeaurora.org (commit_signer:2/16=12%) Peter Ujfalusi peter.ujfal...@ti.com (commit_signer:2/16=12%) Alan Cox a...@linux.intel.com (commit_signer:2/16=12%) linux-in...@vger.kernel.org (open list:INPUT (KEYBOARD,...) linux-ker...@vger.kernel.org (open list) Thanks. Replied with them in CC. Drew Signed-off-by: Andrew Jones drjo...@redhat.com --- drivers/input/misc/Kconfig |2 +- drivers/video/Kconfig |1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 22d875f..36c15bf 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C config INPUT_XEN_KBDDEV_FRONTEND tristate Xen virtual keyboard and mouse support - depends on XEN_FBDEV_FRONTEND + depends on XEN This is OK with me. default y select XEN_XENBUS_FRONTEND help diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d83e967..269b299 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND select FB_SYS_IMAGEBLIT select FB_SYS_FOPS select FB_DEFERRED_IO + select INPUT_XEN_KBDDEV_FRONTEND But here you need to either depend on or select INPUT as select does not resolve dependencies for selected symbol. Would I actually need 'select INPUT' and select 'INPUT_MISC'? Maybe 'depends on' would just be cleaner and safer. I'll send a V2. Thanks, Drew Thanks. -- Dmitry ___ Xen-devel mailing list xen-de...@lists.xensource.com http://lists.xensource.com/xen-devel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote: On Mon, Jan 09, 2012 at 11:39:44AM +, Stefano Stabellini wrote: I don't think we should add PCI_XEN SWIOTLB_XEN X86_LOCAL_APIC X86_IO_APIC ACPI PCI to XEN either. However it should be possible to add only the right dependencies to the right places. In practice it should be sufficient to: - make PCI_XEN depend on X86_LOCAL_APIC X86_IO_APIC ACPI; Not good. You can make non-ACPI builds with PCI. .. and you are missing CONFIG_PCI in there. - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN; OK. That sounds good. - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c. No.. same issue - non-ACPI builds can be with PCI. Right.. in that case we should carefully replace the 'ifdef CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c. It would effectively keep things as they are now: if ACPI and XEN are enabled together in the config file, your kernel is able to setup interrupts when running as DOM0. Regarding X86_LOCAL_APIC and X86_IO_APIC I cannot recall anymore where these dependencies come from exactly. The driver domain concept may actually be the technical need for making XEN_DOM0 optional. If we want the ability to build a minimally configed XEN kernel to be used as a driver domain, then it doesn't seem like we'd want it to also be capable of running as an initial domain, or to be forced to have all the dependencies and code of an initial domain. In practice any decent driver domain needs PCI and ACPI support, so basically it has the same config requirement of XEN_DOM0. At that point Sure.. for backends. But for frontends that requirement is not always true. Right but a driver domain is bound to have at least the pci backend. we have already discussed that having XEN_DOM0 enabled or disabled hardly makes any differences, so we can just get rid of it. Or in other words, substitute it as CONFIG_PCI_XEN. I was just trying to assign the dependencies where they really belong and I proposed to remove the 'ifdef CONFIG_ACPI' because I didn't realize that one can build working PCI configurations on XEN without it. The fact that PCI_XEN would be used then almost as XEN_DOM0 is used now is just a side effect, due to the fact that PCI and device interrupts initialization is what mainly differentiates dom0 from other configurations. But this brings a question about MCE, ACPI cpu freq and ACPI S3. Those all belong to the dom0 - not to any driver domain. So getting rid of CONFIG_XEN_DOM0 would present a problem - what would those depend on? They would depend on XEN and whatever else they really depend on, for example ACPI. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
- Original Message - On Mon, Jan 09, 2012 at 04:12:10PM +, Stefano Stabellini wrote: On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote: On Mon, Jan 09, 2012 at 11:39:44AM +, Stefano Stabellini wrote: I don't think we should add PCI_XEN SWIOTLB_XEN X86_LOCAL_APIC X86_IO_APIC ACPI PCI to XEN either. However it should be possible to add only the right dependencies to the right places. In practice it should be sufficient to: - make PCI_XEN depend on X86_LOCAL_APIC X86_IO_APIC ACPI; Not good. You can make non-ACPI builds with PCI. .. and you are missing CONFIG_PCI in there. - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN; OK. That sounds good. - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c. No.. same issue - non-ACPI builds can be with PCI. Right.. in that case we should carefully replace the 'ifdef CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c. .. which I think I did at some point as part of cleanup and then removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI. What about PVonHVM. There is this nagging feeling in the back of my head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option? Or something like that? Maybe it is the other way around? It would seem we need to seperate the PVHVM from DOM0. But the extra complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff with PVonHVM (should be searchable on xen-devel to find the patches). They're currently separate, i.e. no problem with DOM0 off and PVHVM on, or vice-versa afaict. I don't know anything about the hybrid though. Ian also mentioned that we MUST have the XEN_PRIVILIGED option, otherwise we will cause a regression with the GRUB tools. So that must stay or we need provide a deprecation schedule for the next 3 years to remove it and have patches in the GRUB toolchains. Yeah, that's a bummer. Either way, there is also the question of making sure that no regressions are introduced - so a lot of the CONFIG_* interdependencies will have to be checked. I think that means checking CONFIG_XEN, CONFIG_PRIVILIGED, CONFIG_PVHVM, CONFIG_PCI, CONFIG_ACPI, CONFIG_XEN_BACKEND in various combinations. I guess if we did the s/XEN_DOM0/LOCAL_APIC IO_APIC ACPI/ in arch/x86/pci/xen.c it would be pretty easy to review for equivalence. Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and compile in the 3 files. I don't think it makes much sense to do it though. XEN_DOM0 keeps things tidier now and might be useful later. Oh, I forgot CONFIG_XEN_FRONTEND.. And I think that one can also become a module (ditto for XEN_BACKEND) And everytime we did something to those we managed to mess them up so we should be dilligient. ___ Xen-devel mailing list xen-de...@lists.xensource.com http://lists.xensource.com/xen-devel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 2/4 v2] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but they don't use the xen frame buffer frontend. For this case it doesn't make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e. if you're using xenfb, then you'll want xenkbd. Switch the dependencies. Signed-off-by: Andrew Jones drjo...@redhat.com --- drivers/input/misc/Kconfig |2 +- drivers/video/Kconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 22d875f..36c15bf 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C config INPUT_XEN_KBDDEV_FRONTEND tristate Xen virtual keyboard and mouse support - depends on XEN_FBDEV_FRONTEND + depends on XEN default y select XEN_XENBUS_FRONTEND help diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d83e967..3e38c2f 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2263,7 +2263,7 @@ config FB_VIRTUAL config XEN_FBDEV_FRONTEND tristate Xen virtual frame buffer support - depends on FB XEN + depends on FB XEN INPUT_XEN_KBDDEV_FRONTEND select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT -- 1.7.7.5 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 3/4 v2] xen kconfig: add dom0 support help text
Describe dom0 support in the config menu and supply help text for it. v2 adds 'if EXPERT' to keep it out of the standard menu. Signed-off-by: Andrew Jones drjo...@redhat.com --- arch/x86/xen/Kconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 26c731a..31ec975 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -14,9 +14,14 @@ config XEN Xen hypervisor. config XEN_DOM0 - def_bool y + bool Xen Initial Domain (Dom0) support if EXPERT + default y depends on XEN PCI_XEN SWIOTLB_XEN depends on X86_LOCAL_APIC X86_IO_APIC ACPI PCI + help + This allows the kernel to be used for the initial Xen domain, + Domain0. This is a privileged guest that supplies backends + and is used to manage the other Xen domains. # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST # name in tools. -- 1.7.7.5 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote: On Mon, Jan 09, 2012 at 04:12:10PM +, Stefano Stabellini wrote: On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote: On Mon, Jan 09, 2012 at 11:39:44AM +, Stefano Stabellini wrote: I don't think we should add PCI_XEN SWIOTLB_XEN X86_LOCAL_APIC X86_IO_APIC ACPI PCI to XEN either. However it should be possible to add only the right dependencies to the right places. In practice it should be sufficient to: - make PCI_XEN depend on X86_LOCAL_APIC X86_IO_APIC ACPI; Not good. You can make non-ACPI builds with PCI. .. and you are missing CONFIG_PCI in there. - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN; OK. That sounds good. - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c. No.. same issue - non-ACPI builds can be with PCI. Right.. in that case we should carefully replace the 'ifdef CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c. .. which I think I did at some point as part of cleanup and then removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI. that's unfortunate What about PVonHVM. There is this nagging feeling in the back of my head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option? Or something like that? Maybe it is the other way around? nope, nothing I can think of. It would seem we need to seperate the PVHVM from DOM0. But the extra complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff with PVonHVM (should be searchable on xen-devel to find the patches). I think that at the moment PVHVM and DOM0 aren't tie to one another in any way, apart from the fact that they use the same generic infrastructure to remap interrupts and MSIs into event channels. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
On Mon, 9 Jan 2012, Andrew Jones wrote: I guess if we did the s/XEN_DOM0/LOCAL_APIC IO_APIC ACPI/ in arch/x86/pci/xen.c it would be pretty easy to review for equivalence. Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and compile in the 3 files. I don't think it makes much sense to do it though. XEN_DOM0 keeps things tidier now and might be useful later. we can keep things clean with the following: #ifdef CONFIG_LOCAL_APIC CONFIG_IO_APIC CONFIG_ACPI CONFIG_PCI_XEN #define XEN_DOM0 #endif in include/xen/xen.h. So in the source files we can still '#ifdef XEN_DOM0', but at the same time we can get rid of the build symbol: everybody wins. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
Hi Andrew, On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote: - Original Message - On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote: PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but they don't use the xen frame buffer frontend. For this case it doesn't make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e. if you're using xenfb, then you'll want xenkbd. Switch the dependencies. You need to CC as well these people that have 'maintainer' field on them: konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f drivers/video/Kconfig Florian Tobias Schandinat florianschandi...@gmx.de (maintainer:FRAMEBUFFER LAYER) linux-fb...@vger.kernel.org (open list:FRAMEBUFFER LAYER) linux-ker...@vger.kernel.org (open list) konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f drivers/input/misc/Kconfig Dmitry Torokhov dmitry.torok...@gmail.com (maintainer:INPUT (KEYBOARD,...,commit_signer:9/16=56%) Samuel Ortiz sa...@linux.intel.com (commit_signer:3/16=19%) Anirudh Ghayal agha...@codeaurora.org (commit_signer:2/16=12%) Peter Ujfalusi peter.ujfal...@ti.com (commit_signer:2/16=12%) Alan Cox a...@linux.intel.com (commit_signer:2/16=12%) linux-in...@vger.kernel.org (open list:INPUT (KEYBOARD,...) linux-ker...@vger.kernel.org (open list) Thanks. Replied with them in CC. Drew Signed-off-by: Andrew Jones drjo...@redhat.com --- drivers/input/misc/Kconfig |2 +- drivers/video/Kconfig |1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 22d875f..36c15bf 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C config INPUT_XEN_KBDDEV_FRONTEND tristate Xen virtual keyboard and mouse support - depends on XEN_FBDEV_FRONTEND + depends on XEN This is OK with me. default y select XEN_XENBUS_FRONTEND help diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d83e967..269b299 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND select FB_SYS_IMAGEBLIT select FB_SYS_FOPS select FB_DEFERRED_IO + select INPUT_XEN_KBDDEV_FRONTEND But here you need to either depend on or select INPUT as select does not resolve dependencies for selected symbol. Thanks. -- Dmitry ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
