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

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



On Wed, Feb 4, 2015 at 12:29 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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?

OK I'll keep this under CONFIG_XEN alone then...

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

OK I won't add any dependencies to XENFS then, it will remain under CONFIG_XEN.

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

OK I'll keep it simply under CONFIG_XEN...

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

OK thanks I'll keep that simply under CONFIG_XEN.

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

OK.

>>>>   XEN_TMEM
>>>>   XEN_PRIVCMD
>>>
>>> Backend select this?
>
> Why? There's no connection between these and backend functionality.

OK, will keep them under CONFIG_XEN.

 Luis

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