[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen's Linux kernel config options V2



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@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.