[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] RFC: xen config changes v4
On 02/26/2015 02:53 AM, Luis R. Rodriguez wrote:
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
So we are again in the situation that pv-drivers always imply the pvops
kernel (PARAVIRT selected). I started the whole Kconfig rework to
eliminate this dependency.
Can't we move selection of PARAVIRT[-CLOCK] to XEN_PV[H]? This could
be done in a separate series after this one together with the effort
to be able to build the frontend drivers without PARAVIRT, if this
requires some large code rework.
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
XEN_BUILD_HYPERVISOR_SUPPORT?
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
This naming is strange. The memory setup via xen_memory_setup() is
surely more complex than without it. XEN_BUILD_PV_MEMORY_SETUP
perhaps?
Juergen
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
