Re: Xen's Linux kernel config options V2

[Juergen Gross <jgross@suse.com>]

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
>