Re: [Xen-devel] Xen's Linux kernel config options

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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?


>     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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel