Re: [PATCH v3 5/6] xen/arm: report clock_frequency via sysctl physinfo, not createdomain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.07.2026 16:11, Julian Vetter wrote:> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -120,7 +120,26 @@ struct xen_sysctl_physinfo {
>      uint32_t cpu_khz;
>      uint32_t capabilities;/* XEN_SYSCTL_PHYSCAP_??? */
>      uint32_t arch_capabilities;/* XEN_SYSCTL_PHYSCAP_{X86,ARM,...}_??? */
> -    uint32_t pad;
> +    /*
> +     * ARM only, and only set when booting via Device Tree. Value, in Hz, of
> +     * the "clock-frequency" property in the DT timer node. The property may
> +     * be present when the bootloader/firmware doesn't correctly set CNTFRQ
> +     * to hold the timer frequency.

Is this latter aspect relevant for this sysctl field?

> +     * As it's not possible to trap this register, we have to replicate the
> +     * value in the guest DT.

What is "this register" in this context?

> +     * This field mirrors the DT property (a single <u32> cell), independent 
> of
> +     * CNTFRQ_EL0's own width or any given implementation's actual frequency.
> +     * Should the DT binding ever grow a wider encoding, this field would 
> need
> +     * to grow (or gain a companion) to match, same as any other ABI change.
> +     *
> +     * = 0 => property not present, non-ARM, or booting via ACPI (ACPI
> +     *        guests get the frequency from firmware/CNTFRQ instead, so
> +     *        there is nothing to replicate).

As per the initial part of the comment, CNTFREQ may be set correctly, and the
property be absent in that case. Why can't the register value then be made
available here, to reduce the number of constraints?

Jan