All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	JBeulich@suse.com, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, stefano.stabellini@eu.citrix.com,
	mcgrof@do-not-panic.com
Cc: xen-devel@lists.xensource.com
Subject: Re: Xen's Linux kernel config options v3
Date: Mon, 09 Feb 2015 07:17:23 +0100	[thread overview]
Message-ID: <54D850F3.10109@suse.com> (raw)
In-Reply-To: <20150206234442.GZ19988@wotan.suse.de>

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
>

  parent reply	other threads:[~2015-02-09  6:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2015-02-09 19:52   ` Luis R. Rodriguez
2015-02-10  4:41     ` Juergen Gross
2015-02-10 20:27       ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D850F3.10109@suse.com \
    --to=jgross@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.