[PATCH v3 00/18] KVM: arm64: Rework timer offsetting for fun and profit

Marc Zyngier maz at kernel.org
Thu Mar 30 10:46:17 PDT 2023


On Wed, 29 Mar 2023 06:41:07 +0100,
"Veith, Simon" <sveith at amazon.de> wrote:
> 
> Hello Marc,
> 
> thanks again for your proposal.
> 
> On Fri, 2023-03-24 at 14:46 +0000, Marc Zyngier wrote:
> > This series aims at satisfying multiple goals:
> > 
> > - allow a VMM to atomically restore a timer offset for a whole VM
> >   instead of updating the offset each time a vcpu get its counter
> >   written
> > 
> > - allow a VMM to save/restore the physical timer context, something
> >   that we cannot do at the moment due to the lack of offsetting
> > 
> > - provide a framework that is suitable for NV support, where we get
> >   both global and per timer, per vcpu offsetting, and manage
> >   interrupts in a less braindead way.
> > 
> > We fix a couple of issues along the way, both from a stylistic and
> > correctness perspective. This results in a new per VM KVM API that
> > allows a global offset to be set at any point in time, overriding
> > both
> > of the timer counter writebacks.
> > 
> > We also take this opportunity to rework the way IRQs are associated
> > with timers, something that was always a bit dodgy. This relies on a
> > new lock, which should disappear once Oliver's lock ordering series
> > is
> > merged (we can reuse the config_lock for this).
> > 
> > This has been tested with nVHE, VHE and NV. I do not have access to
> > CNTPOFF-aware HW, but Colton managed to give it a go. Note that the
> > NV patches in this series are here to give a perspective on how this
> > gets used.
> > 
> > I've updated the arch_timer selftest to allow an offset to be
> > provided
> > from the command line, and fixed a couple of glaring issues along the
> > way.
> > 
> > Note that this is at best 6.4 material. I have a branch stashed at
> > [0]
> > and based on 6.3-rc3, as well as a minimal example of the use of the
> > API at [3] based on kvmtool.
> > 
> > Simon: I'd appreciate some feedback as whether this change fits your
> > requirements, given that you brought this up the first place.
> 
> The interface looks good to me. I have yet to deliver on my promise to
> test your patch series with our userspace; I am on leave this week, but
> I'll give your latest iteration a go next week.

No worries. I'm about to post v4, which I think is pretty ripe at this
stage. Do let me know when you get a chance to try it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list