From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: Xen's Linux kernel config options Date: Mon, 15 Dec 2014 12:00:32 +0100 Message-ID: <548EBF50.1080100@suse.com> References: <548AEAE7.8020604@suse.com> <20141212164407.GB28140@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141212164407.GB28140@laptop.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , David Vrabel , Jan Beulich , "Ian.Campbell@citrix.com" List-Id: xen-devel@lists.xenproject.org On 12/12/2014 05:44 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote: >> Hi, >> >> This is a design proposal for a rework of the config options on the >> Linux kernel which are related to Xen. >> >> The need to do so arose from the fact that it is currently not >> possible to build the Xen frontend drivers for a non-pvops kernel, >> e.g. to run them in a HVM-domain. There are more drawbacks in the >> current config options to which I'll come later. >> >> Current Xen related config options are as follows: >> >> Option Selects Depends >> --------------------------------------------------------------------- >> XEN PARAVIRT_CLOCK(x86) PARAVIRT(x86) >> XEN_HAVE_PVMMU(x86) >> SWIOTLB_XEN(arm,arm64) >> PCI_XEN(x86) SWIOTLB_XEN >> XEN_DOM0 PCI_XEN(x86) >> XEN_BACKEND >> XEN_BLKDEV_BACKEND >> XEN_PCIDEV_BACKEND(x86) >> XEN_SCSI_BACKEND >> XEN_NETDEV_BACKEND >> XEN_ACPI_HOTPLUG_MEMORY XEN_STUB >> XEN_ACPI_HOTPLUG_CPU XEN_STUB >> XEN_MCE_LOG(x86) >> XEN_PVHVM(x86) >> XEN_PVH(x86) >> XEN_MAX_DOMAIN_MEMORY(x86) >> XEN_SAVE_RESTORE(x86) >> XEN_DEBUG_FS(x86) >> XEN_FBDEV_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND >> XEN_BLKDEV_FRONTEND XEN_XENBUS_FRONTEND >> HVC_XEN >> HVC_XEN_FRONTEND XEN_XENBUS_FRONTEND >> TCG_XEN XEN_XENBUS_FRONTEND >> XEN_PCIDEV_FRONTEND PCI_XEN >> XEN_XENBUS_FRONTEND >> XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND >> XEN_WDT >> XEN_BALLOON >> XEN_SELFBALLOONING XEN_TMEM >> XEN_BALLOON_MEMORY_HOTPLUG >> XEN_SCRUB_PAGES >> XEN_DEV_EVTCHN >> XENFS XEN_PRIVCMD >> XEN_COMPAT_XENFS >> XEN_SYS_HYPERVISOR >> XEN_XENBUS_FRONTEND >> XEN_GNTDEV >> XEN_GRANT_DEV_ALLOC >> SWIOTLB_XEN >> XEN_TMEM(x86) >> XEN_PRIVCMD >> XEN_STUB(x86_64) BROKEN >> XEN_ACPI_PROCESSOR(x86) >> XEN_HAVE_PVMMU >> XEN_EFI(x64) >> XEN_NETDEV_FRONTEND XEN_XENBUS_FRONTEND >> >> Legend: >> - The first column are the Xen config options. Indentation in this >> column reflects the dependency between those options (e.g. >> XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on >> XEN_DOM0, which depends on XEN). >> - The second column shows the options which are selected automatically >> if the corresponding option in the first column is configured. >> - The last column shows additional dependencies which can't be shown via >> the indentation level of the first column. >> - Some options or dependencies are architecture specific, they are >> listed in brackets (e.g. XEN_TMEM which is available for x86 only). >> - Non-Xen options are mentioned only if they seem to be really relevant, >> like e.g. PARAVIRT or BROKEN. >> >> There are several reasons to change the config options: >> - Be able to build Xen frontend drivers for HVM domains without the need >> for choosing a pvops kernel: currently the frontend drivers need XEN >> configured which depends on PARAVIRT. >> - Be able to build a Dom0 using XEN_PVH without having to configure >> XEN_HAVE_PVMMU. >> - Be able to build HVM driver domains. >> - Some features are available for x86 only, in spite of being not >> architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM. >> >> As a first draft I'd suggest the following: >> >> Option Selects Depends >> ---------------------------------------------------------------------- >> XEN SWIOTLB_XEN(arm,arm64) >> XEN_PV(x86) XEN_HAVE_PVMMU >> PARAVIRT >> PARAVIRT_CLOCK >> XEN_PVH(x86) XEN_PVHVM >> PARAVIRT >> PARAVIRT_CLOCK >> XEN_BACKEND XEN_PV(x86) || >> XEN_PVH(x86) || >> XEN_PVHVM >> 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) > > Could XEN_DOM0 be removed completly? And instead we just have > an 'backend' and 'frontend' type options? What about (physical) memory/cpu hotplug and mce? We could rename XEN_DOM0 to XEN_HWDOM, however. > > >> XEN_ACPI_HOTPLUG_MEMORY XEN_STUB >> XEN_ACPI_HOTPLUG_CPU XEN_STUB >> XEN_MCE_LOG(x86) >> XEN_MAX_DOMAIN_MEMORY(x86) >> XEN_SAVE_RESTORE(x86) >> XEN_DEBUG_FS >> XEN_WDT >> XEN_BALLOON >> XEN_SELFBALLOONING XEN_TMEM >> XEN_BALLOON_MEMORY_HOTPLUG >> XEN_SCRUB_PAGES >> XENFS XEN_PRIVCMD >> XEN_COMPAT_XENFS >> XEN_SYS_HYPERVISOR >> XEN_DEV_EVTCHN >> XEN_GNTDEV >> XEN_GRANT_DEV_ALLOC >> SWIOTLB_XEN >> XEN_TMEM >> XEN_PRIVCMD >> XEN_STUB(x86_64) BROKEN >> XEN_ACPI_PROCESSOR(x86) >> XEN_HAVE_PVMMU >> XEN_EFI(x64) >> XEN_PVHVM >> XEN_FRONTEND XEN_PV || >> XEN_PVH || >> XEN_PVHVM >> XEN_XENBUS_FRONTEND >> XEN_FBDEV_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND >> XEN_BLKDEV_FRONTEND XEN_XENBUS_FRONTEND >> HVC_XEN_FRONTEND XEN_XENBUS_FRONTEND >> HVC_XEN >> TCG_XEN XEN_XENBUS_FRONTEND >> XEN_PCIDEV_FRONTEND PCI_XEN >> XEN_XENBUS_FRONTEND >> XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND >> INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND >> XEN_NETDEV_FRONTEND XEN_XENBUS_FRONTEND >> >> There might be some further adjustments needed (should XEN_DEV_EVTCHN >> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The >> main difference to the current status is the XEN setting no longer >> controlling all other options. >> >> Changing the config options in this way surely will need some >> adjustments in the drivers, but this can be discussed when we agree >> on the future config dependencies. >> >> >> Juergen >