mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Julian Vetter
baaa185201
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@vates.tech> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
41 lines
1.2 KiB
C
41 lines
1.2 KiB
C
/*
|
|
* xen/arch/arm/vtimer.h
|
|
*
|
|
* ARM Virtual Timer emulation support
|
|
*
|
|
* Ian Campbell <ian.campbell@citrix.com>
|
|
* Copyright (c) 2011 Citrix Systems.
|
|
*
|
|
* This program is free software; you can redistribute it and/or modify
|
|
* it under the terms of the GNU General Public License as published by
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
* (at your option) any later version.
|
|
*
|
|
* This program is distributed in the hope that it will be useful,
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
* GNU General Public License for more details.
|
|
*/
|
|
|
|
#ifndef __ARCH_ARM_VTIMER_H__
|
|
#define __ARCH_ARM_VTIMER_H__
|
|
|
|
extern int domain_vtimer_init(struct domain *d);
|
|
extern int vcpu_vtimer_init(struct vcpu *v);
|
|
extern bool vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
|
|
extern void virt_timer_save(struct vcpu *v);
|
|
extern void virt_timer_restore(struct vcpu *v);
|
|
extern void vcpu_timer_destroy(struct vcpu *v);
|
|
void vtimer_update_irqs(struct vcpu *v);
|
|
|
|
#endif
|
|
|
|
/*
|
|
* Local variables:
|
|
* mode: C
|
|
* c-file-style: "BSD"
|
|
* c-basic-offset: 4
|
|
* indent-tabs-mode: nil
|
|
* End:
|
|
*/
|