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
