* 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
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-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 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 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
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
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-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-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
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 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-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
* 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
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.