|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v6 4/5] xen/arm: report clock_frequency via sysctl physinfo, not createdomain
On Mon, Sep 28, 2026 at 02:20:00PM +0200, Julian Vetter wrote: > The xen_arch_domainconfig.clock_frequency value is populated in > domain_vtimer_init() during XEN_DOMCTL_createdomain from the global > timer_dt_clock_frequency, which comes from the host's DT timer node and > has nothing to do with the domain being created. Like now removed > GIC_NATIVE resolution, this is a host-wide system property being > smuggled out through a domain-creation IN struct. > > Expose it instead as a new arm_clock_frequency_hz field in > XEN_SYSCTL_physinfo, populated via arch_do_physinfo(), and mirroring how > the GIC capability bits were already moved there. > > Rather than making the field dependant on DT boot, make Xen always > report the timer frequency, either via the DT "clock-frequency" node, or > directly via CNTFRQ_EL0. preinit_xen_time() already computes cpu_khz for > every boot path. The renamed timer_clock_frequency_hz now captures > whichever of the two produced that value, in full Hz precision, instead > of only recording the DT case. So, ACPI guests get a real value too, > allowing to drop the special case. > > The DT "clock-frequency" property exists because firmware might leave > CNTFRQ_EL0 wrong, and since CNTFRQ_EL0 cannot be trapped the only fix is > to replicate the correct value into the guest DT. To keep that signal, a > new XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ capability bit records whether > arm_clock_frequency_hz came from the DT property. Then libxl only emits > a "clock-frequency" property into the guest timer node when that bit is > set. A guest whose CNTFRQ_EL0 is already correct keeps an unmodified > timer node, exactly as before. > > Although the CNTFRQ_EL0 register is 64 bits wide, and some current timer > implementations run at 1GHz, a 32bit value is sufficient to store the > timer value, because it only mirrors the DT 'clock-frequency' property, > which the bindings define as a single 32-bit cell. > > In struct xen_sysctl_physinfo the new field just reuses the former pad > word, so sysctl consumers are unaffected. struct xen_arch_domainconfig > however loses clock_frequency from its middle, which shrinks the struct > and shifts every field after it, so bump XEN_DOMCTL_INTERFACE_VERSION. > > The xen_arch_domainconfig parameter passed to domain_vtimer_init() is no > longer needed, so drop that parameter entirely. libxl now fetches the > frequency via libxl_get_physinfo() in libxl__arch_domain_save_config() > instead of reading it back out of the createdomain reply. The OCaml > xen_arch_domainconfig mirror drops the field too. > > Signed-off-by: Julian Vetter <julian.vetter@xxxxxxxxxx> > Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx> > --- > Changes in v6: > - Rename arch_clock_frequency_hz to arm_clock_frequency_hz > - Drop now-redundant "# ARM only" comment on the libxl IDL entry > - Rework libxl__arch_domain_save_config() to a single exit point: fetch > physinfo up front and use "goto out" on every error path > - Move the gic_version IN/OUT -> IN comment update to the GIC_NATIVE > removal patch > - Added Reviewed-by Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |