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

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



>>> On 04.02.15 at 01:48, <mcgrof@xxxxxxxxxxxxxxxx> 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


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