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

["Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx>]

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 ?

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