Re: Xen's Linux kernel config options V2

From: "Jan Beulich" <JBeulich@suse.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Juergen Gross <JGross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Luis Rodriguez <Mcgrof@Suse.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: Xen's Linux kernel config options V2
Date: Wed, 04 Feb 2015 08:29:58 +0000	[thread overview]
Message-ID: <54D1E696020000780005CAB3@mail.emea.novell.com> (raw)
In-Reply-To: <CAB=NE6XEkFA7Vkr+K=MQk5-_b-Wg9WqmaXe0KhC47QYUs7CjvQ@mail.gmail.com>

>>> On 04.02.15 at 01:48, <mcgrof@do-not-panic.com> wrote:
> 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.

Why do you think HVM can't use ballooning?

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

In general I think options should be hidden only if they can't work
in certain cases.

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

Again - don't hide options that may end up being useful, unless there
is a reason they can't possibly work.

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

I think this can be useful even without any (kernel based) backends
or frontends (e.g. for user mode ones). It's also needed for certain
daemons.

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

Just like for the evtchn device, this is useful to user mode even without
any kernel based backends.

>>>   XEN_TMEM
>>>   XEN_PRIVCMD
>>
>> Backend select this?

Why? There's no connection between these and backend functionality.

Jan