On Thu, 23 Feb 2023 22:29:29 +0000, Colton Lewis <coltonlewis@xxxxxxxxxx> 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@xxxxxxxxxx> 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.