[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen's Linux kernel config options v3
On Sat, 7 Feb 2015, Luis R. Rodriguez wrote: > This is a third respin for a design proposal for a rework on the config > options > on the Linux kernel related to Xen. The frist two proposals came from Juergen, > I'm taking on the work now as some other work I am doing is related to this. > This third iteration addresses the feedback given on Juergen's last v2 > proposal. Let me know if there are any questions or any further feedback > before > we start addressing the changes. > > Reasons to consider a cleanup / reorganizing of the kconfig options: > > - Everything depends on Xen but that's obviously not right. For instance > we want to 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. > - XEN should not depend on PAE, we can have HVM guests without PAE. > - Some features are available for x86 only, in spite of these not being > architecture specific, e.g. XEN_DEBUG_FS > - Be able to build a Dom0 using XEN_PVH(x86) without having to configure > XEN_HAVE_PVMMU(x86). > > Current Xen related config options are as follows: > > 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 with the architecture requirements in parens (e.g. XEN_TMEM(x86) > 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. > - All listed options are user selectable, options which are not user > selectable but > automatic are prefixed with a '*' on the left hand side to make emphasis > > 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_ACPI_PROCESSOR(x86) ACPI_PROCESSOR > CPU_FREQ > 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 It looks good > After some feedback for the first draft I'd suggest the following: > > Option Selects Depends > ---------------------------------------------------------------------- > XEN > XEN_PV(x86) XEN_HAVE_PVMMU(x86) > PARAVIRT > PARAVIRT_CLOCK > XEN_PVH(x86) XEN_PVHVM > PARAVIRT > PARAVIRT_CLOCK > XEN_PVHVM(x86) PARAVIRT > PARAVIRT_CLOCK > XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) || > XEN_PVH(x86) || > XEN_PVHVM(x86) > XEN_TMEM(x86) > XEN_PRIVCMD > 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_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 > XEN_XENBUS_FRONTEND > 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 > XEN_PLATFORM_PCI(x86) this one too > Changes since v2: > > * Add XEN_ACPI_PROCESSOR (Konrad) > * XEN_MAX_DOMAIN_MEMORY(x86) depends on XEN_HAVE_PVMMU(x86) now (Juergen). > Juergen will later replace this once he adds > 500 GiB pv-domains > * Clarifications on some lose options, we seem to want to keep these > user selectable to be able to allow userspace options which do not depend > on xen backend / frontends: ballooning, xenfs, sysfs, event dev, gntdev > (Jan) > * Tons of clarifications on x86 specific options (Stefano), this includes > XEN_PVHVM(x86) > > Luis > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |