[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 +0000, 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |