xen/arch/arm/Makefile | 4 ++-- xen/arch/arm/vsmc.c | 3 ++- xen/common/Makefile | 4 ++-- xen/include/xen/monitor.h | 9 +++++++++ xen/include/xen/vm_event.h | 14 +++++++++++--- 5 files changed, 26 insertions(+), 8 deletions(-)
From: Stefano Stabellini <stefano.stabellini@amd.com>
Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
and monitoring support optional.
This is to reduce code size on Arm when this option isn't enabled.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
xen/arch/arm/Makefile | 4 ++--
xen/arch/arm/vsmc.c | 3 ++-
xen/common/Makefile | 4 ++--
xen/include/xen/monitor.h | 9 +++++++++
xen/include/xen/vm_event.h | 14 +++++++++++---
5 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 43ab5e8f25..8903eb0bf2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
obj-$(CONFIG_MEM_ACCESS) += mem_access.o
obj-y += mm.o
-obj-y += monitor.o
+obj-$(CONFIG_MEM_ACCESS) += monitor.o
obj-y += p2m.o
obj-y += platform.o
obj-y += platform_hypercall.o
@@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
obj-$(CONFIG_GICV3) += vgic-v3.o
obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
endif
-obj-y += vm_event.o
+obj-$(CONFIG_MEM_ACCESS) += vm_event.o
obj-y += vtimer.o
obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
obj-y += vsmc.o
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 62d8117a12..1c13326bdf 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
}
/* If monitor is enabled, let it handle the call. */
- if ( current->domain->arch.monitor.privileged_call_enabled )
+ if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
+ current->domain->arch.monitor.privileged_call_enabled )
rc = monitor_smc();
if ( rc == 1 )
diff --git a/xen/common/Makefile b/xen/common/Makefile
index cba3b32733..e3c6a857ab 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -54,7 +54,7 @@ obj-y += timer.o
obj-$(CONFIG_TRACEBUFFER) += trace.o
obj-y += version.o
obj-y += virtual_region.o
-obj-y += vm_event.o
+obj-$(CONFIG_MEM_ACCESS) += vm_event.o
obj-$(CONFIG_HAS_VMAP) += vmap.o
obj-y += vsprintf.o
obj-y += wait.o
@@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
obj-y += domctl.o
-obj-y += monitor.o
+obj-$(CONFIG_MEM_ACCESS) += monitor.o
obj-y += sysctl.o
endif
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 713d54f7c1..f1359abb94 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -27,8 +27,17 @@
struct domain;
struct xen_domctl_monitor_op;
+#ifdef CONFIG_MEM_ACCESS
int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
void monitor_guest_request(void);
+#else
+static inline int monitor_domctl(struct domain *d,
+ struct xen_domctl_monitor_op *mop)
+{
+ return -EINVAL;
+}
+static inline void monitor_guest_request(void) {}
+#endif
int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 9a86358b42..72e720e378 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -50,9 +50,6 @@ struct vm_event_domain
unsigned int last_vcpu_wake_up;
};
-/* Clean up on domain destruction */
-void vm_event_cleanup(struct domain *d);
-
/* Returns whether a ring has been set up */
bool vm_event_check_ring(struct vm_event_domain *ved);
@@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
vm_event_request_t *req);
+#ifdef CONFIG_MEM_ACCESS
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d);
int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
+#else
+static inline void vm_event_cleanup(struct domain *d) {}
+static inline int vm_event_domctl(struct domain *d,
+ struct xen_domctl_vm_event_op *vec)
+{
+ return -EINVAL;
+}
+#endif
void vm_event_vcpu_pause(struct vcpu *v);
void vm_event_vcpu_unpause(struct vcpu *v);
--
2.25.1On 30.12.2024 07:30, Sergiy Kibrik wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> 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.
Jan
> This is to reduce code size on Arm when this option isn't enabled.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
> xen/arch/arm/Makefile | 4 ++--
> xen/arch/arm/vsmc.c | 3 ++-
> xen/common/Makefile | 4 ++--
> xen/include/xen/monitor.h | 9 +++++++++
> xen/include/xen/vm_event.h | 14 +++++++++++---
> 5 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 43ab5e8f25..8903eb0bf2 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
> obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
> obj-$(CONFIG_MEM_ACCESS) += mem_access.o
> obj-y += mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
> obj-y += p2m.o
> obj-y += platform.o
> obj-y += platform_hypercall.o
> @@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
> obj-$(CONFIG_GICV3) += vgic-v3.o
> obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
> endif
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
> obj-y += vtimer.o
> obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
> obj-y += vsmc.o
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..1c13326bdf 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> }
>
> /* If monitor is enabled, let it handle the call. */
> - if ( current->domain->arch.monitor.privileged_call_enabled )
> + if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
> + current->domain->arch.monitor.privileged_call_enabled )
> rc = monitor_smc();
>
> if ( rc == 1 )
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index cba3b32733..e3c6a857ab 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -54,7 +54,7 @@ obj-y += timer.o
> obj-$(CONFIG_TRACEBUFFER) += trace.o
> obj-y += version.o
> obj-y += virtual_region.o
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
> obj-$(CONFIG_HAS_VMAP) += vmap.o
> obj-y += vsprintf.o
> obj-y += wait.o
> @@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
>
> ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> obj-y += domctl.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
> obj-y += sysctl.o
> endif
>
> diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
> index 713d54f7c1..f1359abb94 100644
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
> struct domain;
> struct xen_domctl_monitor_op;
>
> +#ifdef CONFIG_MEM_ACCESS
> int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
> void monitor_guest_request(void);
> +#else
> +static inline int monitor_domctl(struct domain *d,
> + struct xen_domctl_monitor_op *mop)
> +{
> + return -EINVAL;
> +}
> +static inline void monitor_guest_request(void) {}
> +#endif
>
> int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
>
> diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
> index 9a86358b42..72e720e378 100644
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -50,9 +50,6 @@ struct vm_event_domain
> unsigned int last_vcpu_wake_up;
> };
>
> -/* Clean up on domain destruction */
> -void vm_event_cleanup(struct domain *d);
> -
> /* Returns whether a ring has been set up */
> bool vm_event_check_ring(struct vm_event_domain *ved);
>
> @@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
> void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
> vm_event_request_t *req);
>
> +#ifdef CONFIG_MEM_ACCESS
> +/* Clean up on domain destruction */
> +void vm_event_cleanup(struct domain *d);
> int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
> +#else
> +static inline void vm_event_cleanup(struct domain *d) {}
> +static inline int vm_event_domctl(struct domain *d,
> + struct xen_domctl_vm_event_op *vec)
> +{
> + return -EINVAL;
> +}
> +#endif
>
> void vm_event_vcpu_pause(struct vcpu *v);
> void vm_event_vcpu_unpause(struct vcpu *v);
On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 30.12.2024 07:30, Sergiy Kibrik wrote: > > From: Stefano Stabellini <stefano.stabellini@amd.com> > > > > 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. Tamas
On 06.01.2025 15:05, Tamas K Lengyel wrote: > On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 30.12.2024 07:30, Sergiy Kibrik wrote: >>> From: Stefano Stabellini <stefano.stabellini@amd.com> >>> >>> 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). Jan
On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 06.01.2025 15:05, Tamas K Lengyel wrote: > > On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 30.12.2024 07:30, Sergiy Kibrik wrote: > >>> From: Stefano Stabellini <stefano.stabellini@amd.com> > >>> > >>> 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
On 06.01.2025 19:09, Tamas K Lengyel wrote: > On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 06.01.2025 15:05, Tamas K Lengyel wrote: >>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 30.12.2024 07:30, Sergiy Kibrik wrote: >>>>> From: Stefano Stabellini <stefano.stabellini@amd.com> >>>>> >>>>> 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. Jan
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@suse.com> wrote: >>> >>> On 06.01.2025 15:05, Tamas K Lengyel wrote: >>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>> >>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote: >>>>>> From: Stefano Stabellini <stefano.stabellini@amd.com> >>>>>> >>>>>> 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
On 16.01.2025 12:29, Sergiy Kibrik wrote: > 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@suse.com> wrote: >>>> >>>> On 06.01.2025 15:05, Tamas K Lengyel wrote: >>>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote: >>>>>>> From: Stefano Stabellini <stefano.stabellini@amd.com> >>>>>>> >>>>>>> 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? Things need to remain in sync throughout the tree, so I don't think you can leave out e.g. defconfigs when doing the renamed. Similarly stuff under automation/ may need changing at the same time. Jan
On Mon, 30 Dec 2024, Sergiy Kibrik wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> and monitoring support optional.
> This is to reduce code size on Arm when this option isn't enabled.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
I would add my reviewed-by but I wrote an early draft of this patch...
That said, it looks OK to me.
> ---
> xen/arch/arm/Makefile | 4 ++--
> xen/arch/arm/vsmc.c | 3 ++-
> xen/common/Makefile | 4 ++--
> xen/include/xen/monitor.h | 9 +++++++++
> xen/include/xen/vm_event.h | 14 +++++++++++---
> 5 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 43ab5e8f25..8903eb0bf2 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
> obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
> obj-$(CONFIG_MEM_ACCESS) += mem_access.o
> obj-y += mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
> obj-y += p2m.o
> obj-y += platform.o
> obj-y += platform_hypercall.o
> @@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
> obj-$(CONFIG_GICV3) += vgic-v3.o
> obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
> endif
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
> obj-y += vtimer.o
> obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
> obj-y += vsmc.o
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..1c13326bdf 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> }
>
> /* If monitor is enabled, let it handle the call. */
> - if ( current->domain->arch.monitor.privileged_call_enabled )
> + if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
> + current->domain->arch.monitor.privileged_call_enabled )
> rc = monitor_smc();
>
> if ( rc == 1 )
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index cba3b32733..e3c6a857ab 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -54,7 +54,7 @@ obj-y += timer.o
> obj-$(CONFIG_TRACEBUFFER) += trace.o
> obj-y += version.o
> obj-y += virtual_region.o
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
> obj-$(CONFIG_HAS_VMAP) += vmap.o
> obj-y += vsprintf.o
> obj-y += wait.o
> @@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
>
> ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> obj-y += domctl.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
> obj-y += sysctl.o
> endif
>
> diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
> index 713d54f7c1..f1359abb94 100644
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
> struct domain;
> struct xen_domctl_monitor_op;
>
> +#ifdef CONFIG_MEM_ACCESS
> int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
> void monitor_guest_request(void);
> +#else
> +static inline int monitor_domctl(struct domain *d,
> + struct xen_domctl_monitor_op *mop)
> +{
> + return -EINVAL;
> +}
> +static inline void monitor_guest_request(void) {}
> +#endif
>
> int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
>
> diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
> index 9a86358b42..72e720e378 100644
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -50,9 +50,6 @@ struct vm_event_domain
> unsigned int last_vcpu_wake_up;
> };
>
> -/* Clean up on domain destruction */
> -void vm_event_cleanup(struct domain *d);
> -
> /* Returns whether a ring has been set up */
> bool vm_event_check_ring(struct vm_event_domain *ved);
>
> @@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
> void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
> vm_event_request_t *req);
>
> +#ifdef CONFIG_MEM_ACCESS
> +/* Clean up on domain destruction */
> +void vm_event_cleanup(struct domain *d);
> int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
> +#else
> +static inline void vm_event_cleanup(struct domain *d) {}
> +static inline int vm_event_domctl(struct domain *d,
> + struct xen_domctl_vm_event_op *vec)
> +{
> + return -EINVAL;
> +}
> +#endif
>
> void vm_event_vcpu_pause(struct vcpu *v);
> void vm_event_vcpu_unpause(struct vcpu *v);
> --
> 2.25.1
>
On 02/01/2025 19:34, Stefano Stabellini wrote: > CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. > > > On Mon, 30 Dec 2024, Sergiy Kibrik wrote: >> From: Stefano Stabellini <stefano.stabellini@amd.com> >> >> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events >> and monitoring support optional. >> This is to reduce code size on Arm when this option isn't enabled. >> >> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> - Ayan
© 2016 - 2025 Red Hat, Inc.