* Xen's Linux kernel config options v3
@ 2015-02-06 23:44 Luis R. Rodriguez
2015-02-08 11:35 ` Stefano Stabellini
2015-02-09 6:17 ` Juergen Gross
0 siblings, 2 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06 23:44 UTC (permalink / raw)
To: jgross, david.vrabel, Ian.Campbell, JBeulich, konrad.wilk,
boris.ostrovsky, stefano.stabellini, mcgrof, mcgrof
Cc: xen-devel
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
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)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen's Linux kernel config options v3
2015-02-06 23:44 Xen's Linux kernel config options v3 Luis R. Rodriguez
@ 2015-02-08 11:35 ` Stefano Stabellini
2015-02-09 6:17 ` Juergen Gross
1 sibling, 0 replies; 6+ messages in thread
From: Stefano Stabellini @ 2015-02-08 11:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: jgross, xen-devel, Ian.Campbell, stefano.stabellini, mcgrof,
david.vrabel, JBeulich, boris.ostrovsky
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen's Linux kernel config options v3
2015-02-06 23:44 Xen's Linux kernel config options v3 Luis R. Rodriguez
2015-02-08 11:35 ` Stefano Stabellini
@ 2015-02-09 6:17 ` Juergen Gross
2015-02-09 19:52 ` Luis R. Rodriguez
1 sibling, 1 reply; 6+ messages in thread
From: Juergen Gross @ 2015-02-09 6:17 UTC (permalink / raw)
To: Luis R. Rodriguez, david.vrabel, Ian.Campbell, JBeulich,
konrad.wilk, boris.ostrovsky, stefano.stabellini, mcgrof
Cc: xen-devel
On 02/07/2015 12:44 AM, 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
>
> 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
Wrong indentation of above 2 entries
Juergen
> 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)
>
> 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@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen's Linux kernel config options v3
2015-02-09 6:17 ` Juergen Gross
@ 2015-02-09 19:52 ` Luis R. Rodriguez
2015-02-10 4:41 ` Juergen Gross
0 siblings, 1 reply; 6+ messages in thread
From: Luis R. Rodriguez @ 2015-02-09 19:52 UTC (permalink / raw)
To: Juergen Gross, konrad.wilk, JBeulich
Cc: xen-devel, Ian.Campbell, stefano.stabellini, mcgrof, david.vrabel,
boris.ostrovsky
On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote:
> On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote:
>> 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
>
> Wrong indentation of above 2 entries
I had moved this to select based on Konrad's suggestion that the backend
selects this but then Jan noted this is not necessarily true given that there
is no connection between these and backend functionality and forgot to move it
out under. As such I'll remove both completely from selects -- but its not clear
to me that XEN_BACKEND should depend on both as it seems (maybe I misunderstood)
you are implying, should it?
Do we just want to keep both as is today?
Option Selects Depends
----------------------------------------------------------------------
XEN
XEN_TMEM(x86) !ARM && !ARM64 (default m if CLEANCACHE || FRONTSWAP)
XEN_PRIVCMD
config XEN_TMEM
tristate
depends on !ARM && !ARM64
default m if (CLEANCACHE || FRONTSWAP)
help
Shim to interface in-kernel Transcendent Memory hooks
(e.g. cleancache and frontswap) to Xen tmem hypercalls.
config XEN_PRIVCMD
tristate
depends on XEN
default m
We at least remove that explicit 'depneds on XEN' as it is already part of the
Kconfig file top level mainmenu, but that's a trivial obvious change.
Luis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen's Linux kernel config options v3
2015-02-09 19:52 ` Luis R. Rodriguez
@ 2015-02-10 4:41 ` Juergen Gross
2015-02-10 20:27 ` Luis R. Rodriguez
0 siblings, 1 reply; 6+ messages in thread
From: Juergen Gross @ 2015-02-10 4:41 UTC (permalink / raw)
To: Luis R. Rodriguez, konrad.wilk, JBeulich
Cc: xen-devel, Ian.Campbell, mcgrof, stefano.stabellini, david.vrabel,
boris.ostrovsky
On 02/09/2015 08:52 PM, Luis R. Rodriguez wrote:
> On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote:
>> On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote:
>>> 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
>>
>> Wrong indentation of above 2 entries
>
> I had moved this to select based on Konrad's suggestion that the backend
> selects this but then Jan noted this is not necessarily true given that there
> is no connection between these and backend functionality and forgot to move it
> out under. As such I'll remove both completely from selects -- but its not clear
> to me that XEN_BACKEND should depend on both as it seems (maybe I misunderstood)
> you are implying, should it?
>
> Do we just want to keep both as is today?
>
> Option Selects Depends
> ----------------------------------------------------------------------
> XEN
> XEN_TMEM(x86) !ARM && !ARM64 (default m if CLEANCACHE || FRONTSWAP)
> XEN_PRIVCMD
This is what I meant. Just let them depend on XEN like before.
Juergen
>
> config XEN_TMEM
> tristate
> depends on !ARM && !ARM64
> default m if (CLEANCACHE || FRONTSWAP)
> help
> Shim to interface in-kernel Transcendent Memory hooks
> (e.g. cleancache and frontswap) to Xen tmem hypercalls.
>
> config XEN_PRIVCMD
> tristate
> depends on XEN
> default m
>
> We at least remove that explicit 'depneds on XEN' as it is already part of the
> Kconfig file top level mainmenu, but that's a trivial obvious change.
>
> Luis
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen's Linux kernel config options v3
2015-02-10 4:41 ` Juergen Gross
@ 2015-02-10 20:27 ` Luis R. Rodriguez
0 siblings, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2015-02-10 20:27 UTC (permalink / raw)
To: Juergen Gross
Cc: xen-devel, Ian.Campbell, stefano.stabellini, mcgrof, david.vrabel,
JBeulich, boris.ostrovsky
On Tue, Feb 10, 2015 at 05:41:42AM +0100, Juergen Gross wrote:
> On 02/09/2015 08:52 PM, Luis R. Rodriguez wrote:
>> On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote:
>>> On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote:
>>>> 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
>>>
>>> Wrong indentation of above 2 entries
>>
>> I had moved this to select based on Konrad's suggestion that the backend
>> selects this but then Jan noted this is not necessarily true given that there
>> is no connection between these and backend functionality and forgot to move it
>> out under. As such I'll remove both completely from selects -- but its not clear
>> to me that XEN_BACKEND should depend on both as it seems (maybe I misunderstood)
>> you are implying, should it?
>>
>> Do we just want to keep both as is today?
>>
>> Option Selects Depends
>> ----------------------------------------------------------------------
>> XEN
>> XEN_TMEM(x86) !ARM && !ARM64 (default m if CLEANCACHE || FRONTSWAP)
>> XEN_PRIVCMD
>
> This is what I meant. Just let them depend on XEN like before.
OK!
Luis
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-02-10 20:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-06 23:44 Xen's Linux kernel config options v3 Luis R. Rodriguez
2015-02-08 11:35 ` Stefano Stabellini
2015-02-09 6:17 ` Juergen Gross
2015-02-09 19:52 ` Luis R. Rodriguez
2015-02-10 4:41 ` Juergen Gross
2015-02-10 20:27 ` Luis R. Rodriguez
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.