All of lore.kernel.org
 help / color / mirror / Atom feed
* Xen's Linux kernel config options V2
@ 2014-12-16 16:21 Juergen Gross
  2015-01-09 19:02 ` Konrad Rzeszutek Wilk
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Juergen Gross @ 2014-12-16 16:21 UTC (permalink / raw)
  To: xen-devel, David Vrabel, Ian.Campbell, Jan Beulich,
	Konrad Rzeszutek Wilk, Boris Ostrovsky

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)
   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_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           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.


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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2014-12-16 16:21 Xen's Linux kernel config options V2 Juergen Gross
@ 2015-01-09 19:02 ` Konrad Rzeszutek Wilk
  2015-02-04  0:48   ` Luis R. Rodriguez
  2015-01-19 13:28 ` Ian Campbell
  2015-02-04 10:54 ` David Vrabel
  2 siblings, 1 reply; 23+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-01-09 19:02 UTC (permalink / raw)
  To: Juergen Gross
  Cc: Boris Ostrovsky, xen-devel, David Vrabel, Jan Beulich, Ian.Campbell

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

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2014-12-16 16:21 Xen's Linux kernel config options V2 Juergen Gross
  2015-01-09 19:02 ` Konrad Rzeszutek Wilk
@ 2015-01-19 13:28 ` Ian Campbell
  2015-01-19 13:59   ` Jan Beulich
                     ` (2 more replies)
  2015-02-04 10:54 ` David Vrabel
  2 siblings, 3 replies; 23+ messages in thread
From: Ian Campbell @ 2015-01-19 13:28 UTC (permalink / raw)
  To: Juergen Gross; +Cc: Boris Ostrovsky, xen-devel, David Vrabel, Jan Beulich

On Tue, 2014-12-16 at 17:21 +0100, Juergen Gross wrote:
> Option                          Selects                 Depends
> ----------------------------------------------------------------------

Could you annotate (maybe not a new column, perhaps with a * or
something) which options are supposed to be user-visible vs purely
internal things which can be selected?

I think it is still the case that selecting an option which is user
visible is frowned upon?

[...]
> The main difference to the current status is the XEN setting no longer
> controlling all other options.

In your list do the options which come under XEN or XEN_FRONTEND depend
on the respective headline config option?

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  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
  2 siblings, 1 reply; 23+ messages in thread
From: Jan Beulich @ 2015-01-19 13:59 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Juergen Gross, Boris Ostrovsky, xen-devel, DavidVrabel

>>> On 19.01.15 at 14:28, <Ian.Campbell@citrix.com> wrote:
> I think it is still the case that selecting an option which is user
> visible is frowned upon?

I don't think so; iirc there are cases where things deliberately get
set up that way (for example library code that is explicitly meant
to be available also to out-of-tree drivers, but which some in-tree
drivers also need and hence select).

Jan

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-01-09 19:02 ` Konrad Rzeszutek Wilk
@ 2015-02-04  0:48   ` Luis R. Rodriguez
  2015-02-04  4:58     ` Juergen Gross
  2015-02-04  8:29     ` Jan Beulich
  0 siblings, 2 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-04  0:48 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk, Stefano Stabellini
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Luis R. Rodriguez,
	David Vrabel, Jan Beulich, Boris Ostrovsky

I'm going to work on this now so my replies below.

Note: If we want feature to require XEN_PV || XEN_PVH || XEN_PVHVM,
since XEN_BACKEND depends on them I think we could just use
XEN_BACKEND as a shorthand. Furthermore if we then wanted something to
be available for both backend and frontend we could use a dependency
on XEN_BACKEND || XEN_FRONTEND. Thoughts?

On Fri, Jan 9, 2015 at 11:02 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Dec 16, 2014 at 05:21:05PM +0100, Juergen Gross wrote:
>> After some feedback for the first draft I'd suggest the following:
>>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN
>>   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)

Added.

>>   XEN_MAX_DOMAIN_MEMORY(x86)
>
> which depends on XEN_PV

Adjusted, but so far that's the only XEN_PV alone-dependent option.
Are you sure ? This defines MAX_DOMAIN_PAGES, and used on
arch/x86/xen/setup.c for xen_get_max_pages(). Can't this be used for
XEN_DOM0 ?

>>   XEN_SAVE_RESTORE(x86)
>>   XEN_DEBUG_FS
>>   XEN_WDT
>
> .. which only makes sense in a XEN_DOM0? Perhaps make it part of XEN_DOM0?

Adjusted.

>>   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?

I think this could be further compartmentalized. For XEN_BALLOON,
XEN_SELFBALLOONING, XEN_BALLOON_MEMORY_HOTPLUG, and XEN_SCRUB_PAGES we
have:

static int __init balloon_init(void)
{
        if (!xen_domain())
                return -ENODEV;

        pr_info("Initialising balloon driver\n");

        register_balloon(&balloon_dev);

        register_xen_selfballooning(&balloon_dev);

        register_xenstore_notifier(&xenstore_notifier);

        return 0;
}
subsys_initcall(balloon_init);


So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
sure how ballooning would be used on HVM only domains although right
now ballooning would indeed be initialized in such situations, should
it not? If it should not then the above check should be for
xen_pvh_domain() not just xen_domain(). If it should work for hvm
domains too we could perhaps use XEN_BACKEND || XEN_FRONTEND.

As for XENFS we have the same check on init for xen_domain(), we only
have a small difference for two types of cases. If your kernel
supports XEN_DOM0 you also get exposed on the xenfs the xsd_kva and
xsd_port which correspond to the xen_store_evtchn and
xen_store_interface respectively. Does it make sense to expose xenfs
for hvms? If so under this new arrangement perhaps it should depend on
XEN_BACKEND || XEN_FRONTEND ?

XEN_SYS_HYPERVISOR just populates the generic /sys/hypervisor/ and
also extends it with Xen specific information, its initialization also
depends on xen_domain() but I cannot think of a reason to have this
for HVM. Perhaps this should depend on XEN_BACKEND only ?

>>   XEN_DEV_EVTCHN
>
> Frontends and backends select this?

This registers /dev/xen/evtchn only if we're in xen_domain(). Do we
want this to user visible selectable option and have it depend on
XEN_BACKEND || XEN_FRONTEND ?

>>   XEN_GNTDEV
>
> Backend should select this?

Based on my review I would think that this should depend on
XEN_BACKEND but be user selectable. I'm hoping Stefano can best decide
this though.

>>   XEN_GRANT_DEV_ALLOC
>>   SWIOTLB_XEN
>
> (Make it hidden?)

As for XEN_GRANT_DEV_ALLOC -- if we have XEN_GTDEV as user selectable
its not clear to me why this would not be, and have it depend on
XEN_BACKEND, Stefano?

As for SWIOTLB_XEN -- should that not just depend on XEN_PV && X86 ?
At least drivers/xen/swiotlb-xen.c describes this as code which
provides an IOMMU for Xen PV guests with PCI passthrough.

>>   XEN_TMEM
>>   XEN_PRIVCMD
>
> Backend select this?

OK

>>   XEN_STUB(x86_64)                                      BROKEN
>>   XEN_ACPI_PROCESSOR(x86)
>>   XEN_HAVE_PVMMU
>>   XEN_EFI(x64)
>>   XEN_XENBUS_FRONTEND
>
> (make it hidden?)

Well XEN_STUB is broken... and its useful for CPU / memory hotplug
only. How about making XEN_STUB depend on XEN_BACKEND?

It seems to me that XEN_ACPI_PROCESSOR should also depend on XEN_BACKEND.

XEN_HAVE_PVMMU is only used when XEN_BALLOON is enabled but only
selected when the big old CONFIG_XEN was enabled. Based on the above
observations on XEN_BALLOON if those dependencies are handled
correctly its not clear to me why not just remove this Kconfig entry.

XEN_EFI is already hidden.

XEN_XENBUS_FRONTEND is more of a frontend monitor access to frontends,
but since its for backends have it just selected by XEN_BACKEND then?

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

OK I've added this as part of an end goal to this effort.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-01-19 13:59   ` Jan Beulich
@ 2015-02-04  0:50     ` Luis R. Rodriguez
  0 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-04  0:50 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Juergen Gross, Boris Ostrovsky, xen-devel, Ian Campbell, DavidVrabel

On Mon, Jan 19, 2015 at 5:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.01.15 at 14:28, <Ian.Campbell@citrix.com> wrote:
>> I think it is still the case that selecting an option which is user
>> visible is frowned upon?
>
> I don't think so; iirc there are cases where things deliberately get
> set up that way (for example library code that is explicitly meant
> to be available also to out-of-tree drivers, but which some in-tree
> drivers also need and hence select).

Agreed here, users don't know so our goal should be just to make it
work right for what is selected.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  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-04  8:29     ` Jan Beulich
  1 sibling, 1 reply; 23+ messages in thread
From: Juergen Gross @ 2015-02-04  4:58 UTC (permalink / raw)
  To: Luis R. Rodriguez, Konrad Rzeszutek Wilk, Stefano Stabellini
  Cc: xen-devel, Ian.Campbell, Luis R. Rodriguez, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
> I'm going to work on this now so my replies below.
>
> Note: If we want feature to require XEN_PV || XEN_PVH || XEN_PVHVM,
> since XEN_BACKEND depends on them I think we could just use
> XEN_BACKEND as a shorthand. Furthermore if we then wanted something to
> be available for both backend and frontend we could use a dependency
> on XEN_BACKEND || XEN_FRONTEND. Thoughts?
>
> On Fri, Jan 9, 2015 at 11:02 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Tue, Dec 16, 2014 at 05:21:05PM +0100, Juergen Gross wrote:
>>> After some feedback for the first draft I'd suggest the following:
>>>
>>> Option                          Selects                 Depends
>>> ----------------------------------------------------------------------
>>> XEN
>>>    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)
>
> Added.
>
>>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>
>> which depends on XEN_PV
>
> Adjusted, but so far that's the only XEN_PV alone-dependent option.
> Are you sure ? This defines MAX_DOMAIN_PAGES, and used on
> arch/x86/xen/setup.c for xen_get_max_pages(). Can't this be used for
> XEN_DOM0 ?

This option will be replaced by another one once my patches for
supporting >500GB pv-domains are ready.

For now you could let it depend on XEN_HAVE_PVMMU. It is relevant for
domUs as well.


Juergen

>
>>>    XEN_SAVE_RESTORE(x86)
>>>    XEN_DEBUG_FS
>>>    XEN_WDT
>>
>> .. which only makes sense in a XEN_DOM0? Perhaps make it part of XEN_DOM0?
>
> Adjusted.
>
>>>    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?
>
> I think this could be further compartmentalized. For XEN_BALLOON,
> XEN_SELFBALLOONING, XEN_BALLOON_MEMORY_HOTPLUG, and XEN_SCRUB_PAGES we
> have:
>
> static int __init balloon_init(void)
> {
>          if (!xen_domain())
>                  return -ENODEV;
>
>          pr_info("Initialising balloon driver\n");
>
>          register_balloon(&balloon_dev);
>
>          register_xen_selfballooning(&balloon_dev);
>
>          register_xenstore_notifier(&xenstore_notifier);
>
>          return 0;
> }
> subsys_initcall(balloon_init);
>
>
> So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
> sure how ballooning would be used on HVM only domains although right
> now ballooning would indeed be initialized in such situations, should
> it not? If it should not then the above check should be for
> xen_pvh_domain() not just xen_domain(). If it should work for hvm
> domains too we could perhaps use XEN_BACKEND || XEN_FRONTEND.
>
> As for XENFS we have the same check on init for xen_domain(), we only
> have a small difference for two types of cases. If your kernel
> supports XEN_DOM0 you also get exposed on the xenfs the xsd_kva and
> xsd_port which correspond to the xen_store_evtchn and
> xen_store_interface respectively. Does it make sense to expose xenfs
> for hvms? If so under this new arrangement perhaps it should depend on
> XEN_BACKEND || XEN_FRONTEND ?
>
> XEN_SYS_HYPERVISOR just populates the generic /sys/hypervisor/ and
> also extends it with Xen specific information, its initialization also
> depends on xen_domain() but I cannot think of a reason to have this
> for HVM. Perhaps this should depend on XEN_BACKEND only ?
>
>>>    XEN_DEV_EVTCHN
>>
>> Frontends and backends select this?
>
> This registers /dev/xen/evtchn only if we're in xen_domain(). Do we
> want this to user visible selectable option and have it depend on
> XEN_BACKEND || XEN_FRONTEND ?
>
>>>    XEN_GNTDEV
>>
>> Backend should select this?
>
> Based on my review I would think that this should depend on
> XEN_BACKEND but be user selectable. I'm hoping Stefano can best decide
> this though.
>
>>>    XEN_GRANT_DEV_ALLOC
>>>    SWIOTLB_XEN
>>
>> (Make it hidden?)
>
> As for XEN_GRANT_DEV_ALLOC -- if we have XEN_GTDEV as user selectable
> its not clear to me why this would not be, and have it depend on
> XEN_BACKEND, Stefano?
>
> As for SWIOTLB_XEN -- should that not just depend on XEN_PV && X86 ?
> At least drivers/xen/swiotlb-xen.c describes this as code which
> provides an IOMMU for Xen PV guests with PCI passthrough.
>
>>>    XEN_TMEM
>>>    XEN_PRIVCMD
>>
>> Backend select this?
>
> OK
>
>>>    XEN_STUB(x86_64)                                      BROKEN
>>>    XEN_ACPI_PROCESSOR(x86)
>>>    XEN_HAVE_PVMMU
>>>    XEN_EFI(x64)
>>>    XEN_XENBUS_FRONTEND
>>
>> (make it hidden?)
>
> Well XEN_STUB is broken... and its useful for CPU / memory hotplug
> only. How about making XEN_STUB depend on XEN_BACKEND?
>
> It seems to me that XEN_ACPI_PROCESSOR should also depend on XEN_BACKEND.
>
> XEN_HAVE_PVMMU is only used when XEN_BALLOON is enabled but only
> selected when the big old CONFIG_XEN was enabled. Based on the above
> observations on XEN_BALLOON if those dependencies are handled
> correctly its not clear to me why not just remove this Kconfig entry.
>
> XEN_EFI is already hidden.
>
> XEN_XENBUS_FRONTEND is more of a frontend monitor access to frontends,
> but since its for backends have it just selected by XEN_BACKEND then?
>
>> Also it would good to have a requirement that XEN not depend on PAE -
>> because we can have HVM guests without PAE.
>
> OK I've added this as part of an end goal to this effort.
>
>   Luis
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04  0:48   ` Luis R. Rodriguez
  2015-02-04  4:58     ` Juergen Gross
@ 2015-02-04  8:29     ` Jan Beulich
  2015-02-06  1:19       ` Luis R. Rodriguez
  1 sibling, 1 reply; 23+ messages in thread
From: Jan Beulich @ 2015-02-04  8:29 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Stefano Stabellini,
	Luis Rodriguez, David Vrabel, Boris Ostrovsky

>>> On 04.02.15 at 01:48, <mcgrof@do-not-panic.com> wrote:
> So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
> sure how ballooning would be used on HVM only domains although right
> now ballooning would indeed be initialized in such situations, should
> it not? If it should not then the above check should be for
> xen_pvh_domain() not just xen_domain(). If it should work for hvm
> domains too we could perhaps use XEN_BACKEND || XEN_FRONTEND.

Why do you think HVM can't use ballooning?

> As for XENFS we have the same check on init for xen_domain(), we only
> have a small difference for two types of cases. If your kernel
> supports XEN_DOM0 you also get exposed on the xenfs the xsd_kva and
> xsd_port which correspond to the xen_store_evtchn and
> xen_store_interface respectively. Does it make sense to expose xenfs
> for hvms? If so under this new arrangement perhaps it should depend on
> XEN_BACKEND || XEN_FRONTEND ?

In general I think options should be hidden only if they can't work
in certain cases.

> XEN_SYS_HYPERVISOR just populates the generic /sys/hypervisor/ and
> also extends it with Xen specific information, its initialization also
> depends on xen_domain() but I cannot think of a reason to have this
> for HVM. Perhaps this should depend on XEN_BACKEND only ?

Again - don't hide options that may end up being useful, unless there
is a reason they can't possibly work.

>>>   XEN_DEV_EVTCHN
>>
>> Frontends and backends select this?
> 
> This registers /dev/xen/evtchn only if we're in xen_domain(). Do we
> want this to user visible selectable option and have it depend on
> XEN_BACKEND || XEN_FRONTEND ?

I think this can be useful even without any (kernel based) backends
or frontends (e.g. for user mode ones). It's also needed for certain
daemons.

>>>   XEN_GNTDEV
>>
>> Backend should select this?
> 
> Based on my review I would think that this should depend on
> XEN_BACKEND but be user selectable. I'm hoping Stefano can best decide
> this though.

Just like for the evtchn device, this is useful to user mode even without
any kernel based backends.

>>>   XEN_TMEM
>>>   XEN_PRIVCMD
>>
>> Backend select this?

Why? There's no connection between these and backend functionality.

Jan

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2014-12-16 16:21 Xen's Linux kernel config options V2 Juergen Gross
  2015-01-09 19:02 ` Konrad Rzeszutek Wilk
  2015-01-19 13:28 ` Ian Campbell
@ 2015-02-04 10:54 ` David Vrabel
  2015-02-04 14:57   ` Stefano Stabellini
  2 siblings, 1 reply; 23+ messages in thread
From: David Vrabel @ 2015-02-04 10:54 UTC (permalink / raw)
  To: Juergen Gross, xen-devel, David Vrabel, Ian.Campbell,
	Jan Beulich, Konrad Rzeszutek Wilk, Boris Ostrovsky

On 16/12/14 16:21, 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.
> 
> 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)
>   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_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           PCI_XEN
>   XEN_SCSI_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND
>   XEN_NETDEV_FRONTEND
>   XEN_PLATFORM_PCI

This looks fine to me.

David

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04 10:54 ` David Vrabel
@ 2015-02-04 14:57   ` Stefano Stabellini
  2015-02-04 15:02     ` Ian Campbell
                       ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Stefano Stabellini @ 2015-02-04 14:57 UTC (permalink / raw)
  To: David Vrabel
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Jan Beulich, Boris Ostrovsky

On Wed, 4 Feb 2015, David Vrabel wrote:
> On 16/12/14 16:21, 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.
> > 
> > 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

PARAVIRT_CLOCK and PARAVIRT are x86 specific.
Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
arm and arm64 as there is just one type of guest, I would rather just
have CONFIG_XEN there.


> >   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)
> >   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

not available on arm and arm64


> >   XEN_PRIVCMD
> >   XEN_STUB(x86_64)                                      BROKEN
> >   XEN_ACPI_PROCESSOR(x86)
> >   XEN_HAVE_PVMMU

x86 specific


> >   XEN_EFI(x64)

FYI soon to be available on arm


> >   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           PCI_XEN

x86 specific for the moment


> >   XEN_SCSI_FRONTEND
> >   INPUT_XEN_KBDDEV_FRONTEND
> >   XEN_NETDEV_FRONTEND
> >   XEN_PLATFORM_PCI

definitely x86 only


> This looks fine to me.
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  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 22:54     ` Luis R. Rodriguez
  2 siblings, 1 reply; 23+ messages in thread
From: Ian Campbell @ 2015-02-04 15:02 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Juergen Gross, xen-devel, David Vrabel, Jan Beulich, Boris Ostrovsky

On Wed, 2015-02-04 at 14:57 +0000, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, David Vrabel wrote:
> > On 16/12/14 16:21, 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.
> > > 
> > > 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
> 
> PARAVIRT_CLOCK and PARAVIRT are x86 specific.

Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
we are going to want that functionality on ARM too, although it's not
clear to me that bundling pv-wallclock and pv-cyclecounter in
arch/x86/kernel/pvclock.c under the same config option is most correct.

Ian.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04 15:02     ` Ian Campbell
@ 2015-02-04 15:06       ` Stefano Stabellini
  0 siblings, 0 replies; 23+ messages in thread
From: Stefano Stabellini @ 2015-02-04 15:06 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Juergen Gross, xen-devel, Stefano Stabellini, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Wed, 4 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-04 at 14:57 +0000, Stefano Stabellini wrote:
> > On Wed, 4 Feb 2015, David Vrabel wrote:
> > > On 16/12/14 16:21, 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.
> > > > 
> > > > 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
> > 
> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> 
> Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
> we are going to want that functionality on ARM too, although it's not
> clear to me that bundling pv-wallclock and pv-cyclecounter in
> arch/x86/kernel/pvclock.c under the same config option is most correct.
 
Agreed.  Also that patch series never went upstream unfortunately.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04  4:58     ` Juergen Gross
@ 2015-02-05 23:59       ` Luis R. Rodriguez
  2015-02-06  0:11         ` Luis R. Rodriguez
  0 siblings, 1 reply; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-05 23:59 UTC (permalink / raw)
  To: Juergen Gross
  Cc: xen-devel, Ian.Campbell, Stefano Stabellini, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Tue, Feb 3, 2015 at 8:58 PM, Juergen Gross <jgross@suse.com> wrote:
> On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
>>>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>>
>>>
>>> which depends on XEN_PV
>>
>>
>> Adjusted, but so far that's the only XEN_PV alone-dependent option.
>> Are you sure ? This defines MAX_DOMAIN_PAGES, and used on
>> arch/x86/xen/setup.c for xen_get_max_pages(). Can't this be used for
>> XEN_DOM0 ?
>
>
> This option will be replaced by another one once my patches for
> supporting >500GB pv-domains are ready.

Great!

> For now you could let it depend on XEN_HAVE_PVMMU. It is relevant for
> domUs as well.

Well right now the only entity that selects XEN_HAVE_PVMMU is
CONFIG_XEN.. so that begs the question of which Kconfig options should
be selecting XEN_HAVE_PVMMU in the future? What about having it be
selected by XEN_BACKEND and also XEN_FRONTEND ?

  Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-05 23:59       ` Luis R. Rodriguez
@ 2015-02-06  0:11         ` Luis R. Rodriguez
  0 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06  0:11 UTC (permalink / raw)
  To: Juergen Gross
  Cc: xen-devel, Ian.Campbell, Stefano Stabellini, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Thu, Feb 5, 2015 at 3:59 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Tue, Feb 3, 2015 at 8:58 PM, Juergen Gross <jgross@suse.com> wrote:
>> On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
>>>>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>>>
>>>>
>>>> which depends on XEN_PV
>>>
>>>
>>> Adjusted, but so far that's the only XEN_PV alone-dependent option.
>>> Are you sure ? This defines MAX_DOMAIN_PAGES, and used on
>>> arch/x86/xen/setup.c for xen_get_max_pages(). Can't this be used for
>>> XEN_DOM0 ?
>>
>>
>> This option will be replaced by another one once my patches for
>> supporting >500GB pv-domains are ready.
>
> Great!
>
>> For now you could let it depend on XEN_HAVE_PVMMU. It is relevant for
>> domUs as well.
>
> Well right now the only entity that selects XEN_HAVE_PVMMU is
> CONFIG_XEN.. so that begs the question of which Kconfig options should
> be selecting XEN_HAVE_PVMMU in the future? What about having it be
> selected by XEN_BACKEND and also XEN_FRONTEND ?

Nevermind I see you had it selected by XEN_PV(x86) already only, this
would also satisfy Konrad's request to be able to build XEN_PVH
without having to configure XEN_HAVE_PVMMU.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04  8:29     ` Jan Beulich
@ 2015-02-06  1:19       ` Luis R. Rodriguez
  0 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06  1:19 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Stefano Stabellini,
	David Vrabel, Boris Ostrovsky

On Wed, Feb 4, 2015 at 12:29 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.02.15 at 01:48, <mcgrof@do-not-panic.com> wrote:
>> So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
>> sure how ballooning would be used on HVM only domains although right
>> now ballooning would indeed be initialized in such situations, should
>> it not? If it should not then the above check should be for
>> xen_pvh_domain() not just xen_domain(). If it should work for hvm
>> domains too we could perhaps use XEN_BACKEND || XEN_FRONTEND.
>
> Why do you think HVM can't use ballooning?

OK I'll keep this under CONFIG_XEN alone then...

>> As for XENFS we have the same check on init for xen_domain(), we only
>> have a small difference for two types of cases. If your kernel
>> supports XEN_DOM0 you also get exposed on the xenfs the xsd_kva and
>> xsd_port which correspond to the xen_store_evtchn and
>> xen_store_interface respectively. Does it make sense to expose xenfs
>> for hvms? If so under this new arrangement perhaps it should depend on
>> XEN_BACKEND || XEN_FRONTEND ?
>
> In general I think options should be hidden only if they can't work
> in certain cases.

OK I won't add any dependencies to XENFS then, it will remain under CONFIG_XEN.

>> XEN_SYS_HYPERVISOR just populates the generic /sys/hypervisor/ and
>> also extends it with Xen specific information, its initialization also
>> depends on xen_domain() but I cannot think of a reason to have this
>> for HVM. Perhaps this should depend on XEN_BACKEND only ?
>
> Again - don't hide options that may end up being useful, unless there
> is a reason they can't possibly work.

OK I'll keep it simply under CONFIG_XEN...

>>>>   XEN_DEV_EVTCHN
>>>
>>> Frontends and backends select this?
>>
>> This registers /dev/xen/evtchn only if we're in xen_domain(). Do we
>> want this to user visible selectable option and have it depend on
>> XEN_BACKEND || XEN_FRONTEND ?
>
> I think this can be useful even without any (kernel based) backends
> or frontends (e.g. for user mode ones). It's also needed for certain
> daemons.

OK thanks I'll keep that simply under CONFIG_XEN.

>>>>   XEN_GNTDEV
>>>
>>> Backend should select this?
>>
>> Based on my review I would think that this should depend on
>> XEN_BACKEND but be user selectable. I'm hoping Stefano can best decide
>> this though.
>
> Just like for the evtchn device, this is useful to user mode even without
> any kernel based backends.

OK.

>>>>   XEN_TMEM
>>>>   XEN_PRIVCMD
>>>
>>> Backend select this?
>
> Why? There's no connection between these and backend functionality.

OK, will keep them under CONFIG_XEN.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04 14:57   ` Stefano Stabellini
  2015-02-04 15:02     ` Ian Campbell
@ 2015-02-06  1:28     ` Luis R. Rodriguez
  2015-02-06 12:07       ` Stefano Stabellini
  2015-02-06 22:54     ` Luis R. Rodriguez
  2 siblings, 1 reply; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06  1:28 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Juergen Gross, xen-devel, Ian.Campbell, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Feb 2015, David Vrabel wrote:
>> On 16/12/14 16:21, 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.
>> >
>> > 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
>
> PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
> arm and arm64 as there is just one type of guest, I would rather just
> have CONFIG_XEN there.

Interesting, right now we have as part of the recommended change for
XEN_BACKEND:

Option                          Selects                 Depends
----------------------------------------------------------------------
XEN
  XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
                                                        XEN_PVH(x86) ||
                                                        XEN_PVHVM

How would we ensure to enable XEN_BACKEND for arm then?

>> >   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)
>> >   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
>
> not available on arm and arm64

Can you clarify if you meant only XEN_TMEM or all the above here?

>> >   XEN_PRIVCMD
>> >   XEN_STUB(x86_64)                                      BROKEN
>> >   XEN_ACPI_PROCESSOR(x86)
>> >   XEN_HAVE_PVMMU
>
> x86 specific

Likewise, all of the above quoted options ?

>> >   XEN_EFI(x64)
>
> FYI soon to be available on arm

OK thanks.

>> >   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           PCI_XEN
>
> x86 specific for the moment

All?

>> >   XEN_SCSI_FRONTEND
>> >   INPUT_XEN_KBDDEV_FRONTEND
>> >   XEN_NETDEV_FRONTEND
>> >   XEN_PLATFORM_PCI
>
> definitely x86 only

All?

  Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-06  1:28     ` Luis R. Rodriguez
@ 2015-02-06 12:07       ` Stefano Stabellini
  2015-02-06 22:51         ` Luis R. Rodriguez
  0 siblings, 1 reply; 23+ messages in thread
From: Stefano Stabellini @ 2015-02-06 12:07 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Stefano Stabellini,
	David Vrabel, Jan Beulich, Boris Ostrovsky

On Thu, 5 Feb 2015, Luis R. Rodriguez wrote:
> On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 4 Feb 2015, David Vrabel wrote:
> >> On 16/12/14 16:21, 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.
> >> >
> >> > 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
> >
> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> > Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
> > arm and arm64 as there is just one type of guest, I would rather just
> > have CONFIG_XEN there.
> 
> Interesting, right now we have as part of the recommended change for
> XEN_BACKEND:
> 
> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN
>   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
>                                                         XEN_PVH(x86) ||
>                                                         XEN_PVHVM
> 
> How would we ensure to enable XEN_BACKEND for arm then?

I thought that you wanted to turn XEN_BACKEND into a user selectable
option.  On arm and arm64 this option wouldn't depend on anything
(except CONFIG_XEN).  


> >> >   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)
> >> >   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
> >
> > not available on arm and arm64
> 
> Can you clarify if you meant only XEN_TMEM or all the above here?

Only TMEM, sorry for being terse


> >> >   XEN_PRIVCMD
> >> >   XEN_STUB(x86_64)                                      BROKEN
> >> >   XEN_ACPI_PROCESSOR(x86)
> >> >   XEN_HAVE_PVMMU
> >
> > x86 specific
> 
> Likewise, all of the above quoted options ?

only XEN_HAVE_PVMMU


> >> >   XEN_EFI(x64)
> >
> > FYI soon to be available on arm
> 
> OK thanks.
> 
> >> >   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           PCI_XEN
> >
> > x86 specific for the moment
> 
> All?

XEN_PCIDEV_FRONTEND and PCI_XEN


> >> >   XEN_SCSI_FRONTEND
> >> >   INPUT_XEN_KBDDEV_FRONTEND
> >> >   XEN_NETDEV_FRONTEND
> >> >   XEN_PLATFORM_PCI
> >
> > definitely x86 only
> 
> All?

only XEN_PLATFORM_PCI

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  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
  0 siblings, 2 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06 22:51 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Juergen Gross, xen-devel, Ian.Campbell, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Fri, Feb 6, 2015 at 4:07 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 5 Feb 2015, Luis R. Rodriguez wrote:
>> On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 4 Feb 2015, David Vrabel wrote:
>> >> On 16/12/14 16:21, 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.
>> >> >
>> >> > 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
>> >
>> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
>> > Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
>> > arm and arm64 as there is just one type of guest, I would rather just
>> > have CONFIG_XEN there.
>>
>> Interesting, right now we have as part of the recommended change for
>> XEN_BACKEND:
>>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN
>>   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
>>                                                         XEN_PVH(x86) ||
>>                                                         XEN_PVHVM
>>
>> How would we ensure to enable XEN_BACKEND for arm then?
>
> I thought that you wanted to turn XEN_BACKEND into a user selectable
> option.  On arm and arm64 this option wouldn't depend on anything
> (except CONFIG_XEN).

OK sure, that maps to this dependency list then:

ARM || ARM64 || ( X86 && (XEN_PV || XEN_PVH || XEN_PVHVM )

>> >> >   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)
>> >> >   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
>> >
>> > not available on arm and arm64
>>
>> Can you clarify if you meant only XEN_TMEM or all the above here?
>
> Only TMEM, sorry for being terse

That was listed as one of the example Kconfig entries which are
currently not available on other architectures despite not being
architecture specific, the other one being XEN_DEBUG_FS. So to be
clear -- do we not want XEN_TMEM for arm in the future ?

>> >> >   XEN_PRIVCMD
>> >> >   XEN_STUB(x86_64)                                      BROKEN
>> >> >   XEN_ACPI_PROCESSOR(x86)
>> >> >   XEN_HAVE_PVMMU
>> >
>> > x86 specific
>>
>> Likewise, all of the above quoted options ?
>
> only XEN_HAVE_PVMMU

Updated.

>> >> >   XEN_EFI(x64)
>> >
>> > FYI soon to be available on arm
>>
>> OK thanks.
>>
>> >> >   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           PCI_XEN
>> >
>> > x86 specific for the moment
>>
>> All?
>
> XEN_PCIDEV_FRONTEND and PCI_XEN

Updated.

>> >> >   XEN_SCSI_FRONTEND
>> >> >   INPUT_XEN_KBDDEV_FRONTEND
>> >> >   XEN_NETDEV_FRONTEND
>> >> >   XEN_PLATFORM_PCI
>> >
>> > definitely x86 only
>>
>> All?
>
> only XEN_PLATFORM_PCI

Updated.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-04 14:57   ` Stefano Stabellini
  2015-02-04 15:02     ` Ian Campbell
  2015-02-06  1:28     ` Luis R. Rodriguez
@ 2015-02-06 22:54     ` Luis R. Rodriguez
  2 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06 22:54 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Juergen Gross, xen-devel, Ian.Campbell, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
> arm and arm64

I'll update CONFIG_XEN_PVHVM to be x86 specific, it already depends on
X86_LOCAL_APIC, so just updating it on the proposal to annotate it is
x86 specific.

  Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-01-19 13:28 ` Ian Campbell
  2015-01-19 13:59   ` Jan Beulich
@ 2015-02-06 23:25   ` Luis R. Rodriguez
  2015-02-06 23:26   ` Luis R. Rodriguez
  2 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06 23:25 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Juergen Gross, Boris Ostrovsky, xen-devel, David Vrabel, Jan Beulich

On Mon, Jan 19, 2015 at 5:28 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Could you annotate (maybe not a new column, perhaps with a * or
> something) which options are supposed to be user-visible vs purely
> internal things which can be selected?

All options listed will be user selectable unless otherwise noted with
a (*) in the next iteration.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-01-19 13:28 ` Ian Campbell
  2015-01-19 13:59   ` Jan Beulich
  2015-02-06 23:25   ` Luis R. Rodriguez
@ 2015-02-06 23:26   ` Luis R. Rodriguez
  2 siblings, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-06 23:26 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Juergen Gross, Boris Ostrovsky, xen-devel, David Vrabel, Jan Beulich

On Mon, Jan 19, 2015 at 5:28 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> In your list do the options which come under XEN or XEN_FRONTEND depend
> on the respective headline config option?

An indentation reflects a dependency on the above option.

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-06 22:51         ` Luis R. Rodriguez
@ 2015-02-08 11:28           ` Stefano Stabellini
  2015-02-12  4:29           ` Luis R. Rodriguez
  1 sibling, 0 replies; 23+ messages in thread
From: Stefano Stabellini @ 2015-02-08 11:28 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Juergen Gross, xen-devel, Ian.Campbell, Stefano Stabellini,
	David Vrabel, Jan Beulich, Boris Ostrovsky

On Fri, 6 Feb 2015, Luis R. Rodriguez wrote:
> On Fri, Feb 6, 2015 at 4:07 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 5 Feb 2015, Luis R. Rodriguez wrote:
> >> On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Wed, 4 Feb 2015, David Vrabel wrote:
> >> >> On 16/12/14 16:21, 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.
> >> >> >
> >> >> > 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
> >> >
> >> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> >> > Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
> >> > arm and arm64 as there is just one type of guest, I would rather just
> >> > have CONFIG_XEN there.
> >>
> >> Interesting, right now we have as part of the recommended change for
> >> XEN_BACKEND:
> >>
> >> Option                          Selects                 Depends
> >> ----------------------------------------------------------------------
> >> XEN
> >>   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
> >>                                                         XEN_PVH(x86) ||
> >>                                                         XEN_PVHVM
> >>
> >> How would we ensure to enable XEN_BACKEND for arm then?
> >
> > I thought that you wanted to turn XEN_BACKEND into a user selectable
> > option.  On arm and arm64 this option wouldn't depend on anything
> > (except CONFIG_XEN).
> 
> OK sure, that maps to this dependency list then:
> 
> ARM || ARM64 || ( X86 && (XEN_PV || XEN_PVH || XEN_PVHVM )

And CONFIG_XEN, right?


> >> >> >   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)
> >> >> >   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
> >> >
> >> > not available on arm and arm64
> >>
> >> Can you clarify if you meant only XEN_TMEM or all the above here?
> >
> > Only TMEM, sorry for being terse
> 
> That was listed as one of the example Kconfig entries which are
> currently not available on other architectures despite not being
> architecture specific, the other one being XEN_DEBUG_FS. So to be
> clear -- do we not want XEN_TMEM for arm in the future ?

Sure, but it is on nobody's roadmap at the moment.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Xen's Linux kernel config options V2
  2015-02-06 22:51         ` Luis R. Rodriguez
  2015-02-08 11:28           ` Stefano Stabellini
@ 2015-02-12  4:29           ` Luis R. Rodriguez
  1 sibling, 0 replies; 23+ messages in thread
From: Luis R. Rodriguez @ 2015-02-12  4:29 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Juergen Gross, xen-devel, Ian.Campbell, David Vrabel,
	Jan Beulich, Boris Ostrovsky

On Fri, Feb 6, 2015 at 2:51 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
>>> >> >   XEN_PLATFORM_PCI
>>> >
>>> > definitely x86 only
>>>
>>> All?
>>
>> only XEN_PLATFORM_PCI
>
> Updated.

Then again commit 5fbdc10395cd500d6ff844825a918c4e6f38de37 removed
this so its no longer relevant as its all folded under XEN_PVHVM

 Luis

^ permalink raw reply	[flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-02-12  4:29 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-16 16:21 Xen's Linux kernel config options V2 Juergen Gross
2015-01-09 19:02 ` Konrad Rzeszutek Wilk
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

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.