On 24.03.2025 07:11, Penny, Zheng wrote: > [Public] > > Hi, > >> -----Original Message----- >> From: Jan Beulich <jbeul...@suse.com> >> Sent: Friday, March 14, 2025 5:27 PM >> To: Penny, Zheng <penny.zh...@amd.com> >> Cc: Huang, Ray <ray.hu...@amd.com>; Stabellini, Stefano >> <stefano.stabell...@amd.com>; Andrew Cooper <andrew.coop...@citrix.com>; >> Anthony PERARD <anthony.per...@vates.tech>; Orzel, Michal >> <michal.or...@amd.com>; Julien Grall <jul...@xen.org>; Roger Pau Monné >> <roger....@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; Sergiy >> Kibrik >> <sergiy_kib...@epam.com>; xen-devel@lists.xenproject.org >> Subject: Re: [PATCH v1 19/19] xen/sysctl: wrap around sysctl hypercall >> >> On 12.03.2025 05:06, Penny Zheng wrote: >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -69,7 +69,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-y += sysctl.o >>> +obj-$(CONFIG_SYSCTL) += sysctl.o >> >> This wants to move back up then, into the main (alphabetically sorted) list >> of >> objects. >> >>> --- a/xen/include/hypercall-defs.c >>> +++ b/xen/include/hypercall-defs.c >>> @@ -195,7 +195,9 @@ kexec_op(unsigned long op, void *uarg) >>> dm_op(domid_t domid, unsigned int nr_bufs, xen_dm_op_buf_t *bufs) >>> #endif #ifndef CONFIG_PV_SHIM_EXCLUSIVE >>> +#ifdef CONFIG_SYSCTL >>> sysctl(xen_sysctl_t *u_sysctl) >>> +#endif >>> domctl(xen_domctl_t *u_domctl) >>> paging_domctl_cont(xen_domctl_t *u_domctl) >>> platform_op(xen_platform_op_t *u_xenpf_op) >>> @@ -274,7 +276,9 @@ physdev_op compat do >>> hvm hvm >> do_arm >>> hvm_op do do do do do >>> #endif >>> #ifndef CONFIG_PV_SHIM_EXCLUSIVE >>> +#ifdef CONFIG_SYSCTL >>> sysctl do do do do do >>> +#endif >>> domctl do do do do do >>> #endif >>> #ifdef CONFIG_KEXEC >> >> As indicated earlier on, PV_SHIM_EXCLUSIVE likely wants / needs sorting as a >> prereq anyway. Otherwise I think the new #ifdef-s better wouldn't end up >> inside the >> PV_SHIM_EXCLUSIVE ones. > > May I ask, if we dropped the earlier commit, not replacing all the > !PV_SHIM_EXCLUSIVE with UNRESTRICTED, > whathat is the next plan for it ?
Didn't I mention this in enough detail in [1]? Stefano said he'd have someone in mind to carry out that work. Stefano - any more concrete indications? Jan [1] https://lists.xen.org/archives/html/xen-devel/2025-03/msg00783.html
