From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RFC: xen config changes v4 Date: Thu, 26 Feb 2015 05:59:51 +0100 Message-ID: <54EEA847.6070505@suse.com> References: <20150226015305.GE8749@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YQqYE-00042z-Qk for xen-devel@lists.xenproject.org; Thu, 26 Feb 2015 04:59:55 +0000 In-Reply-To: <20150226015305.GE8749@wotan.suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" , David Vrabel , Konrad Rzeszutek Wilk , Boris Ostrovsky , Jan Beulich , Stefano Stabellini Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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 >