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.w...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
