|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RFC: xen config changes v4
OK here's the state of affairs after some further discussion on some v3 patch
RFC changes and issues I've found after trying to build front end drivers
without CONFIG_XEN.
Option Selects Depends
----------------------------------------------------------------------
XEN
PARAVIRT(x86)
PARAVIRT_CLOCK(x86)
XEN_PV(x86) XEN_HAVE_PVMMU(x86)
XEN_PVH(x86) XEN_FRONTEND
XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) ||
XEN_PVH(x86) ||
XEN_FRONTEND
XEN_BLKDEV_BACKEND
XEN_PCIDEV_BACKEND(x86)
XEN_SCSI_BACKEND
XEN_NETDEV_BACKEND
PCI_XEN(x86) SWIOTLB_XEN
XEN_DOM0 XEN_BACKEND XEN_PV(x86) ||
PCI_XEN(x86) XEN_PVH(x86)
XEN_ACPI_HOTPLUG_MEMORY XEN_STUB
XEN_ACPI_HOTPLUG_CPU XEN_STUB
XEN_MCE_LOG(x86)
XEN_ACPI_PROCESSOR(x86) ACPI_PROCESSOR
CPU_FREQ
XEN_SAVE_RESTORE(x86)
XEN_DEBUG_FS
XEN_WDT
XEN_MAX_DOMAIN_MEMORY(x86) XEN_HAVE_PVMMU(x86)
XEN_BALLOON
XEN_SELFBALLOONING XEN_TMEM(x86)
XEN_BALLOON_MEMORY_HOTPLUG
XEN_SCRUB_PAGES
XENFS XEN_PRIVCMD
XEN_COMPAT_XENFS
XEN_TMEM(x86)
XEN_PRIVCMD
XEN_SYS_HYPERVISOR
XEN_DEV_EVTCHN
XEN_GNTDEV
XEN_GRANT_DEV_ALLOC
SWIOTLB_XEN
XEN_STUB(x86_64) BROKEN
XEN_ACPI_PROCESSOR(x86)
XEN_HAVE_PVMMU(x86) XEN_PV(x86)
XEN_EFI(x64)
XEN_XENBUS_FRONTEND
XEN_FRONTEND XEN X86_LOCAL_APIC(x86)
XEN_XENBUS_FRONTEND PCI(x86)
XEN_FBDEV_FRONTEND INPUT_XEN_KBDDEV_FRONTEND
XEN_BLKDEV_FRONTEND
HVC_XEN_FRONTEND HVC_XEN
TCG_XEN
XEN_PCIDEV_FRONTEND(x86) PCI_XEN(x86)
XEN_SCSI_FRONTEND
INPUT_XEN_KBDDEV_FRONTEND
XEN_NETDEV_FRONTEND
Additionally I will now note some expected code collateral, none of
this is obviously final but I figure I'll give a heads up as what
I have seen so far or what has helped. Perhaps not all is necessary,
but its best to discuss in case anyone sees anything worth barking
over early.
* Folding XEN_PVHVM under XEN_FRONTEND should enable good
integration and building of frontend drivers without requiring
building the whole xen tamale. That has some obvious code changes
required in place. As a build collateral since XEN_PVH used to
depend on XEN_PVHVM we'll now obviously have XEN_PVH select
XEN_FRONTEND.
* Although technically we never wanted to build XEN_PVHVM without
XEN_PVH we obviously want to build XEN_FRONTEND without XEN_PV
and since we are folding XEN_PVHVM under XEN_FRONTEND we want
to build XEN_FRONTEND without XEN_PV or XEN_PVH. This means
we need to build some old XEN_PVHVM code without requiring
a series of things -- none of this is scary reallyt, its just
putting code into common files and building them when either
a PV guest is Xen frontend drivers are desired. The split of
code also tries to aim to compartamentalize XEN_PV code so
that in the future a swift git rm would enable removal of
XEN_PV code should that be desirable. In order to make the
building of common code and non-common code easier to read
I've added two Kconfig options:
config XEN_BUILD_PV_GUEST
def_bool y if XEN_PV || XEN_PVH
config XEN_BUILD_HYPERVISOR
def_bool y if XEN_PV || XEN_FRONTEND
Naming is perhaps not the best, I welcome other ideas.
Example of where we'd use this:
arch/x86/xen/xen-head.S:#ifdef CONFIG_XEN_BUILD_PV_GUEST
* arch/x86/xen/setup.c has code which only needs to be
built under certain conditions for simple memory set up.
To help with this I've added to arch/x86/xen/Kconfig:
config XEN_BUILD_SIMPLE_MEMORY_SETUP
def_bool y if !XEN_FRONTEND
and on it folded in all the xen_extra_mem, xen_released_pages,
xen_remap_mfn stuff (xen_memory_setup() and friends). As
collateral that also means:
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1560,8 +1566,10 @@ asmlinkage __visible void __init xen_start_kernel(void)
if (xen_feature(XENFEAT_auto_translated_physmap))
x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
+#ifdef CONFIG_XEN_BUILD_SIMPLE_MEMORY_SETUP
else
x86_init.resources.memory_setup = xen_memory_setup;
+#endif
x86_init.oem.arch_setup = xen_arch_setup;
x86_init.oem.banner = xen_banner;
There is some setup.c code which is common, so this helps compartamentalize the
non shared code.
* In terms of shared code we end up with something that looks like this,
desired naming preferences are welcomed, I can also just fold this into
proper xen/ directory but was just lazy for my initial build test:
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -1,7 +1,21 @@
obj-$(CONFIG_KVM) += kvm/
+obj-$(CONFIG_XEN_BUILD_PV_GUEST) += xen/
+
# Xen paravirtualization support
-obj-$(CONFIG_XEN) += xen/
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/common.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/time-common.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/mmu-common.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/p2m-common.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/setup-common.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/irq.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/xen-asm.o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/xen-asm_$(BITS).o
+obj-$(CONFIG_XEN_BUILD_HYPERVISOR) += xen/grant-table.o
+obj-$(CONFIG_XEN_FRONTEND) += xen/hvm.o
+obj-$(CONFIG_XEN_FRONTEND) += xen/hvm-time.o
+obj-$(CONFIG_XEN_FRONTEND) += xen/mmu-hvm.o
+obj-$(CONFIG_XEN_FRONTEND) += xen/platform-pci-unplug.o
If any of this looks fuzzy still you could just wait for a clean
patch series to evaluate better.
Luis
--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |