Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c & monitor.c

[Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>]

07.01.25 10:46, Jan Beulich:
> On 06.01.2025 19:09, Tamas K Lengyel wrote:
> > 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).
> Oh, okay, you suggest to replace MEM_ACCESS by VM_EVENT at the Kconfig
> level. That would be fine with me, so long as it's also appropriate on
> (in particular) x86. Then, if there was ever a 2nd use of mem-access,
> MEM_ACCESS could be re-introduced as a standalone option.
Thanks Jan,
would it be ok to replace MEM_ACCESS with VM_EVENT everywhere at once, 
including in defconfigs and automation script etc? Or such changes would 
better be done gradually, starting with changing Kconfig only?
  -Sergiy