Hi all,
This is a continuation of the disabling some hypercalls handling code series.
https://lore.kernel.org/xen-devel/20250704092952.822578-1-Penny.Zheng@amd.com/

It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling some hypercalls handling code, which may not to be used &
required in such systems. Each hypercall has a separate option to keep
configuration flexible.

Options to disable hypercalls:
- sysctl
- domctl
- hvm
- physdev
- platform_op

This is for platform_op.
---
cc: Jan Beulich <jbeulich@suse.com>
cc: Andrew Cooper <andrew.cooper3@citrix.com>
cc: "Roger Pau Monné" <roger.pau@citrix.com>
cc: Anthony PERARD <anthony.perard@vates.tech>
cc: Michal Orzel <michal.orzel@amd.com>
cc: Julien Grall <julien@xen.org>
cc: Stefano Stabellini <sstabellini@kernel.org>
cc: Lukasz Hawrylko <lukasz@hawrylko.pl>
cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>
cc: "Mateusz Mówka" <mateusz.mowka@intel.com>
cc: Dario Faggioli <dfaggioli@suse.com>
cc: Juergen Gross <jgross@suse.com>
cc: George Dunlap <gwd@xenproject.org>
cc: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
cc: Bertrand Marquis <bertrand.marquis@arm.com>
cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
---
Jiqian Chen (11):
  xen: Introduce CONFIG_PLATFORM_OP
  xen/xsm: Wrap around xsm_platform_op with CONFIG_PLATFORM_OP
  xen/platform_op: Wrap around XENPF_microcode_update(2)
  xen/platform_op: Wrap around XENPF_firmware_info
  xen/platform_op: Wrap around XENPF_efi_runtime_call
  xen/platform_op: Wrap around XENPF_enter_acpi_sleep
  xen/platform_op: Wrap around XENPF_set_processor_pminfo
  xen/xsm: Wrap around xsm_resource_(un)plug_core
  xen/platform_op: Wrap around XENPF_mem_hotadd
  xen/platform_op: Wrap around XENPF_core_parking
  xen/platform_op: Wrap around platform_op hypercall

 xen/arch/arm/Makefile                 |  2 +-
 xen/arch/x86/Makefile                 |  2 ++
 xen/arch/x86/acpi/cpu_idle.c          |  6 ++++++
 xen/arch/x86/acpi/cpufreq/cpufreq.c   |  2 ++
 xen/arch/x86/acpi/lib.c               |  2 ++
 xen/arch/x86/acpi/power.c             |  4 ++++
 xen/arch/x86/apic.c                   |  4 ++++
 xen/arch/x86/configs/pvshim_defconfig |  1 +
 xen/arch/x86/cpu/microcode/core.c     |  6 ++++++
 xen/arch/x86/i8259.c                  |  2 ++
 xen/arch/x86/io_apic.c                |  2 ++
 xen/arch/x86/tboot.c                  |  2 ++
 xen/arch/x86/x86_64/Makefile          |  5 +++--
 xen/arch/x86/x86_64/mm.c              |  6 ++++++
 xen/common/Kconfig                    |  7 +++++++
 xen/common/core_parking.c             |  4 ++++
 xen/common/cpu.c                      |  2 ++
 xen/common/domain.c                   |  4 ++--
 xen/common/efi/common-stub.c          |  4 ++++
 xen/common/efi/compat.c               |  2 ++
 xen/common/efi/runtime.c              |  5 +++++
 xen/common/numa.c                     |  2 ++
 xen/common/sched/core.c               |  2 ++
 xen/drivers/char/console.c            |  6 ++++--
 xen/drivers/cpufreq/cpufreq.c         |  4 ++++
 xen/drivers/passthrough/iommu.c       |  2 ++
 xen/include/hypercall-defs.c          |  6 ++++--
 xen/include/xsm/xsm.h                 | 12 ++++++++++++
 xen/xsm/dummy.c                       |  5 +++++
 xen/xsm/flask/hooks.c                 |  5 +++++
 30 files changed, 109 insertions(+), 9 deletions(-)

-- 
2.34.1

On 25.07.2025 08:15, Jiqian Chen wrote:
> Jiqian Chen (11):
>   xen: Introduce CONFIG_PLATFORM_OP
>   xen/xsm: Wrap around xsm_platform_op with CONFIG_PLATFORM_OP
>   xen/platform_op: Wrap around XENPF_microcode_update(2)
>   xen/platform_op: Wrap around XENPF_firmware_info
>   xen/platform_op: Wrap around XENPF_efi_runtime_call
>   xen/platform_op: Wrap around XENPF_enter_acpi_sleep
>   xen/platform_op: Wrap around XENPF_set_processor_pminfo
>   xen/xsm: Wrap around xsm_resource_(un)plug_core
>   xen/platform_op: Wrap around XENPF_mem_hotadd
>   xen/platform_op: Wrap around XENPF_core_parking
>   xen/platform_op: Wrap around platform_op hypercall

Except for extreme cases, unlike for e.g. sysctl, I think it is dangerous
to compile this out altogether.

Further, nit: While I let Penny's use of "Wrap around ..." as subjects go
as is, the massive use here makes it necessary to indicate that I don't
consider these as meaningful subjects. They simply don't say what is
actually being done by the patch. One possible meaning could be that you
found line wrapping issues, and correct them step by step.

Jan

On 25.07.2025 08:15, Jiqian Chen wrote:
> Hi all,
> This is a continuation of the disabling some hypercalls handling code series.
> https://lore.kernel.org/xen-devel/20250704092952.822578-1-Penny.Zheng@amd.com/
> 
> It can be beneficial for some dom0less systems to further reduce Xen footprint
> via disabling some hypercalls handling code, which may not to be used &
> required in such systems. Each hypercall has a separate option to keep
> configuration flexible.
> 
> Options to disable hypercalls:
> - sysctl
> - domctl
> - hvm

Is this hvmop? If so, how can it reasonably be disabled when the majority of
guests are HVM ones these days? Some of the operations can be invoked by
guests on themselves, iirc.

> - physdev
> - platform_op

For everything else, it's not clear whether it was conveyed to you that there
is a more general argument against this fine-grained splitting at the Kconfig
level. Already with domctl you've learned the hard way that it's intertwined
with e.g. sysctl. The basic direction to move into appears to be to allow to
exclude such special "management" operations via on single control.

In the light of this it's not quite clear how useful it would be to actually
review this series. In any event, before anything further can go in, issues
with what has already gone in will need sorting, imo.

Jan