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

From: Marc Zyngier <maz@kernel.org>
To: Colton Lewis <coltonlewis@google.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, james.morse@arm.com,
	suzuki.poulose@arm.com, oliver.upton@linux.dev,
	yuzenghui@huawei.com, ricarkol@google.com, sveith@amazon.de,
	dwmw2@infradead.org
Subject: Re: [PATCH 00/16] KVM: arm64: Rework timer offsetting for fun and profit
Date: Fri, 24 Feb 2023 08:45:30 +0000	[thread overview]
Message-ID: <865ybrxxhx.wl-maz@kernel.org> (raw)
In-Reply-To: <gsnt4jrc9fsm.fsf@coltonlewis-kvm.c.googlers.com>

On Thu, 23 Feb 2023 22:29:29 +0000,
Colton Lewis <coltonlewis@google.com> wrote:
> 
> Hello Marc,
> 
> This patch is of special interest to me as I was working on my own
> ECV/CNTPOFF implementation, although mine was more narrow and doesn't
> address any of your other goals. As far as I can tell at the moment,
> your patch can cover the uses of mine, so I will dedicate
> myself to reviewing and testing yours. Please include me on any future
> rerolls of this patch.
> 
> Marc Zyngier <maz@kernel.org> writes:
> 
> > 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
> 
> 
> If I am understanding your changes correctly, you introduce some VM-wide
> timers with no hardware backing and a new API to access them from
> userspace. This is useful both because it makes the code simpler (no
> need to manually keep registers in sync), and so CNT{V,P}OFF can be
> appropriately virtualized with NV. Is that a fair summary of the
> important bits?

I think you are conflating a lot of things:

- We always were able to fully emulate a timer: see how non-VHE
  emulates the physical timer. What this allows is to move a HW timer
  from being "direct" to being *partially* emulated, still using the
  HW, but offsetting the counter (and thus requiring trapping).

- CNTPOFF isn't virtualised yet. Actually, none of ECV is virtualised.
  And I'm not convinced it can be virtualised if the HW doesn't
  support it.

- There is no new API for the timers. We only expose the physical
  timer within the existing API. The new API is solely for the purpose
  of setting the offsets.

> 
> > This has been moderately tested with nVHE, VHE and NV. I do not have
> > access to CNTPOFF-aware HW, so the jury is still out on that one. 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 offsets to be provided
> > from the command line, but the arch_test is pretty flimsy and tends to
> > fail with an error==EINTR, even without this series. Something to
> > investigate.
> 
> I can help you with testing because I have access to CNTPOFF-aware
> hardware and emulators. Is there anything you are especially interested
> to try out?

Well, anything that makes use of CNTPOFF would be most helpful,
assuming you're confident that the quality of implementation of the HW
is sufficient (I have terrible memories of finding timer bugs in
emulation due to badly emulated clock domains...).

Thanks,

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel