All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: Xen's Linux kernel config options V2
Date: Fri, 9 Jan 2015 14:02:00 -0500	[thread overview]
Message-ID: <20150109190200.GA4083@l.oracle.com> (raw)
In-Reply-To: <54905BF1.2050608@suse.com>

On Tue, Dec 16, 2014 at 05:21:05PM +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.
> 
> After some feedback for the first draft I'd suggest the following:
> 
> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN
>   XEN_PV(x86)                   XEN_HAVE_PVMMU
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVH(x86)                  XEN_PVHVM
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVHVM                     PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  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)
>     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>     XEN_MCE_LOG(x86)

and XEN_ACPI_PROCESSOR(x86)

>   XEN_MAX_DOMAIN_MEMORY(x86)

which depends on XEN_PV

>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS
>   XEN_WDT

.. which only makes sense in a XEN_DOM0? Perhaps make it part of XEN_DOM0?

>   XEN_BALLOON
>     XEN_SELFBALLOONING                                  XEN_TMEM
>     XEN_BALLOON_MEMORY_HOTPLUG
>     XEN_SCRUB_PAGES
>   XENFS                         XEN_PRIVCMD
>     XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR

Available on all? As in if we select CONFIG_XEN this would automtically show up?

>   XEN_DEV_EVTCHN

Frontends and backends select this?

>   XEN_GNTDEV

Backend should select this?

>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN

(Make it hidden?)
>   XEN_TMEM
>   XEN_PRIVCMD

Backend select this?
>   XEN_STUB(x86_64)                                      BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
>   XEN_XENBUS_FRONTEND

(make it hidden?)

> 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           PCI_XEN
>   XEN_SCSI_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND
>   XEN_NETDEV_FRONTEND
>   XEN_PLATFORM_PCI
> 
> 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.
> 

Also it would good to have a requirement that XEN not depend on PAE -
because we can have HVM guests without PAE.

> 
> Changes in V2:
> - XEN doesn't select SWIOTLB_XEN on arm, this is done by XEN_BACKEND now
>   (David Vrabel and Stefano Stabellini)
> - XEN_PVHVM now under XEN, selects PARAVIRT and PARAVIRT_CLOCK (David)
> - XEN_FRONTEND independent from any XEN_* variant, selects XEN and
>   XEN_XENBUS_FRONTEND (David, Juergen)
> - added XEN_PLATFORM_PCI (David)
> 
> Juergen

  reply	other threads:[~2015-01-09 19:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 16:21 Xen's Linux kernel config options V2 Juergen Gross
2015-01-09 19:02 ` Konrad Rzeszutek Wilk [this message]
2015-02-04  0:48   ` Luis R. Rodriguez
2015-02-04  4:58     ` Juergen Gross
2015-02-05 23:59       ` Luis R. Rodriguez
2015-02-06  0:11         ` Luis R. Rodriguez
2015-02-04  8:29     ` Jan Beulich
2015-02-06  1:19       ` Luis R. Rodriguez
2015-01-19 13:28 ` Ian Campbell
2015-01-19 13:59   ` Jan Beulich
2015-02-04  0:50     ` Luis R. Rodriguez
2015-02-06 23:25   ` Luis R. Rodriguez
2015-02-06 23:26   ` Luis R. Rodriguez
2015-02-04 10:54 ` David Vrabel
2015-02-04 14:57   ` Stefano Stabellini
2015-02-04 15:02     ` Ian Campbell
2015-02-04 15:06       ` Stefano Stabellini
2015-02-06  1:28     ` Luis R. Rodriguez
2015-02-06 12:07       ` Stefano Stabellini
2015-02-06 22:51         ` Luis R. Rodriguez
2015-02-08 11:28           ` Stefano Stabellini
2015-02-12  4:29           ` Luis R. Rodriguez
2015-02-06 22:54     ` 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=20150109190200.GA4083@l.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.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.