[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |