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

From: Marc Zyngier <maz@kernel.org>
To: "Veith, Simon" <sveith@amazon.de>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"coltonlewis@google.com" <coltonlewis@google.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"joey.gouly@arm.com" <joey.gouly@arm.com>,
	"reijiw@google.com" <reijiw@google.com>,
	"ricarkol@google.com" <ricarkol@google.com>
Subject: Re: [PATCH v3 00/18] KVM: arm64: Rework timer offsetting for fun and profit
Date: Thu, 30 Mar 2023 18:46:17 +0100	[thread overview]
Message-ID: <86cz4qw2s6.wl-maz@kernel.org> (raw)
In-Reply-To: <67fd090a26beb831a3ae754853c9419e1cbcfcd8.camel@amazon.de>

On Wed, 29 Mar 2023 06:41:07 +0100,
"Veith, Simon" <sveith@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.