[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.