On Fri, 2020-02-14 at 11:19 +0100, Andrew Jones wrote:
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:
> > 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.
There's plenty of precedents for carrying a name used in KVM/QEMU
over to libvirt, so we're good on that front.
> > 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.
We're explicitly preventing non-virt guests to configure the timer,
so no problem here.
Since all outstanding questions have been answered, I'm going to push
the series now. Thanks Drew for providing these last nuggets of
information, and of course thanks Jano for the review :)
--
Andrea Bolognani / Red Hat / Virtualization