[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen's Linux kernel config options
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
