Re: RFC: xen config changes v4

[Juergen Gross <jgross@suse.com>]

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
>