Message-ID: <87ed00kbe3.ffs@tglx>
Date: Fri, 14 Feb 2025 12:34:44 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: David Woodhouse <dwmw2@...radead.org>, Thomas Weißschuh
 <thomas.weissschuh@...utronix.de>, "James E.J. Bottomley"
 <James.Bottomley@...senPartnership.com>, Helge
 Deller <deller@....de>, Andy Lutomirski <luto@...nel.org>, Vincenzo
 Frascino <vincenzo.frascino@....com>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>, Catalin
 Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Theodore
 Ts'o <tytso@....edu>, "Jason A. Donenfeld" <Jason@...c4.com>, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui
 <kernel@...0n.name>, Russell King <linux@...linux.org.uk>, Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev
 <agordeev@...ux.ibm.com>, Christian Borntraeger
 <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, Thomas
 Bogendoerfer <tsbogend@...ha.franken.de>, Michael Ellerman
 <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Christophe
 Leroy <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>,
 Madhavan
 Srinivasan <maddy@...ux.ibm.com>, Ingo Molnar <mingo@...hat.com>, Borislav
 Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann
 <arnd@...db.de>, Guo Ren <guoren@...nel.org>
Cc: linux-parisc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-riscv@...ts.infradead.org,
 loongarch@...ts.linux.dev, linux-s390@...r.kernel.org,
 linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-arch@...r.kernel.org, Nam Cao <namcao@...utronix.de>,
 linux-csky@...r.kernel.org, "Ridoux, Julien" <ridouxj@...zon.com>, "Luu,
 Ryan" <rluu@...zon.com>, kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 00/18] vDSO: Introduce generic data storage

David!

On Thu, Feb 06 2025 at 09:31, David Woodhouse wrote:
> Thanks for working on this. Is there a plan to expose the time data
> directly to userspace in a form which is usable *other* than by
> function calls which get the value of the clock at a given moment?
>
> For populating the vmclock device¹ we need to know the actual
> relationship between the hardware counter (TSC, arch timer, etc.) and
> real time in order to propagate that to the guest.
>
> I see two options for doing this:
>
>  1. Via userspace, exposing the vdso time data (and a notification when
>     it changes?) and letting the userspace VMM populate the vmclock.
>     This is complex for x86 because of TSC scaling; in fact userspace
>     doesn't currently know the precise scaling from host to guest TSC
>     so we'd have to be able to extract that from KVM.

Exposing the raw data is not going to happen as we would create an ABI
preventing any modifications to the internals. VDSO data is considered a
fully internal (think kernel) representation and the accessor functions
create an ABI around it. So if at all you can add a accessor function
which exposes data to user space so that the internal data
representation can still be modified as necessary.

>  2. In kernel, asking KVM to populate the vmclock structure much like
>     it does other pvclocks shared with the guest. KVM/x86 already uses
>     pvclock_gtod_register_notifier() to hook changes; should we expand
>     on that? The problem with that notifier is that it seems to be
>     called far more frequently than I'd expect.

It's called once per tick to expose the continous updates to the
conversion factors and related internal data.

Thanks,

        tglx

Powered by blists - more mailing lists