From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: Xen's Linux kernel config options V2 Date: Wed, 04 Feb 2015 05:58:53 +0100 Message-ID: <54D1A70D.80906@suse.com> References: <54905BF1.2050608@suse.com> <20150109190200.GA4083@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" , Konrad Rzeszutek Wilk , Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , "Ian.Campbell@citrix.com" , "Luis R. Rodriguez" , David Vrabel , Jan Beulich , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org 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 > 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 >