On Mon, 9 Jan 2012, Andrew Jones wrote: > ----- 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.
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; - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN; - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c. > 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 we have already discussed that having XEN_DOM0 enabled or disabled hardly makes any differences, so we can just get rid of it. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
