[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c & monitor.c
On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@xxxxxxxx> wrote: > > On 06.01.2025 15:05, Tamas K Lengyel wrote: > > On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@xxxxxxxx> wrote: > >> > >> On 30.12.2024 07:30, Sergiy Kibrik wrote: > >>> From: Stefano Stabellini <stefano.stabellini@xxxxxxx> > >>> > >>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM > >>> events > >>> and monitoring support optional. > >> > >> Yet doesn't this end up in things becoming misleading? Don't we rather > >> need a > >> 2nd Kconfig option, with a dependency between the two? Or alternatively a > >> rename of the existing option (to describe the higher-level feature rather > >> than the lower level one)? Tamas, I'm particularly interested in knowing > >> your > >> view here as well. > > > > Thanks Jan, I was thinking the same thing. The dependency of these > > subsystems is mem_access -> monitor -> vm_event. If the goal here is > > to disable all three levels the ideal way would be to have separate > > kconfig options for each level. It may be a bit too fine-grained > > though on ARM since there are only two types of events for monitor > > (SMC & mem_access) and only the monitor uses the vm_event channel (no > > mem-sharing/paging on ARM). So if doing separate kconfig for each > > individual feature is an overkill I would suggest using > > CONFIG_VM_EVENT that disables all three levels, including both > > mem_access & smc monitor hooks. > > Except that "disables all three levels" doesn't work, unless the other > option(s) are promptless (and selected). I'd have expected VM_EVENT to > maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS" > wouldn't make much sense as long as MEM_ACCESS can be enabled > individually (with it being unclear to me whether such a configuration > is actually useful in any way). Not sure I follow. None of these systems make sense to enable individually. Without vm_event monitor/mem_access are useless, that's why I would pick CONFIG_VM_EVENT as the option on ARM to disable all three levels if we don't want to start splitting it into multiple kconfig options (which I think may be an overkill here). Tamas
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |