On Thu, Feb 13, 2020 at 05:30:21PM +0100, Andrea Bolognani wrote: > On Thu, 2020-02-13 at 14:26 +0100, Ján Tomko wrote: > > On Fri, Feb 07, 2020 at 03:27:03PM +0100, Andrea Bolognani wrote: > > > +++ b/src/conf/domain_conf.c > > > @@ -1063,6 +1063,7 @@ VIR_ENUM_IMPL(virDomainTimerName, > > > "tsc", > > > "kvmclock", > > > "hypervclock", > > > + "armvtimer", > > > ); > > > > Okay, so this name is a libvirt invention. > > I believe "ARM virtual timer" is the official name for the device; > the name "armvtimer" is an abbreviation that me and Drew (CC'd) have > agreed upon, and I understand that's fairly commonly used too. > > Drew can confirm whether this is actually the case. To be precise the ARM architecture reference manual refers to the CPU's builtin timer as the "Generic Timer". All CPUs which the QEMU arm 'virt' machine type supports implement the Generic Timer, and all implementations of the Generic Timer must include the virtual counter. The virtual counter is used to indicate virtual time. In both QEMU and KVM when we want to refer to the virtual counter based timer we call it the "vtimer". So, while libvirt is indeed inventing the name "armvtimer", I think it's appropriate. > > > And the timer itself is present on all ARM/virt guests and cannot be > > disabled, correct? > > I believe so but, once again, it'd be better if Drew confirmed it :) Correct. While the Generic Timer is an optional feature of the CPU, all CPUs that the ARM/virt machine type support have it and it cannot be removed. So, all ARM/virt guests have vtimers, but not all ARM guests must have vtimers. If libvirt can start non-'virt' ARM guests, which have different CPUs, then there's a chance that the guest will not have a vtimer. I'm not sure if we want to try and incorporate that much specificity into the libvirt name, though. I think if a machine/CPU doesn't have a vtimer than this XML element should just not be valid. Thanks, drew
