linux-kernel - Re: [PATCH] ptp: Add vDSO-style vmclock support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0959390cad71b451dc19e5f9396d3f4fdb8fd46f.camel@infradead.org>
Date: Thu, 25 Jul 2024 20:35:40 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Richard Cochran <richardcochran@...il.com>, Peter Hilber
 <peter.hilber@...nsynergy.com>, linux-kernel@...r.kernel.org, 
 virtualization@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
 linux-rtc@...r.kernel.org, "Ridoux, Julien" <ridouxj@...zon.com>, 
 virtio-dev@...ts.linux.dev, "Luu, Ryan" <rluu@...zon.com>, "Chashper,
 David" <chashper@...zon.com>, "Mohamed Abuelfotoh, Hazem"
 <abuehaze@...zon.com>,  "Christopher S . Hall"
 <christopher.s.hall@...el.com>, Jason Wang <jasowang@...hat.com>, John
 Stultz <jstultz@...gle.com>,  netdev@...r.kernel.org, Stephen Boyd
 <sboyd@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>, Marc Zyngier <maz@...nel.org>, Mark Rutland
 <mark.rutland@....com>, Daniel Lezcano <daniel.lezcano@...aro.org>,
 Alessandro Zummo <a.zummo@...ertech.it>,  Alexandre Belloni
 <alexandre.belloni@...tlin.com>, qemu-devel <qemu-devel@...gnu.org>, Simon
 Horman <horms@...nel.org>
Subject: Re: [PATCH] ptp: Add vDSO-style vmclock support

On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > The use case isn't necessarily for all users of gettimeofday(), of
> > course; this is for those applications which *need* precision time.
> > Like distributed databases which rely on timestamps for coherency, and
> > users who get fined millions of dollars when LM messes up their clocks
> > and they put wrong timestamps on financial transactions.
> 
> I would however worry that with all this pass through,
> applications have to be coded to each hypervisor or even
> version of the hypervisor.

Yes, that would be a problem. Which is why I feel it's so important to
harmonise the contents of the shared memory, and I'm implementing it
both QEMU and $DAYJOB, as well as aligning with virtio-rtc.

I don't think the structure should be changing between hypervisors (and
especially versions). We *will* see a progression from simply providing
the disruption signal, to providing the full clock information so that
guests don't have to abort transactions while they resync their clock.
But that's perfectly fine.

And it's also entirely agnostic to the mechanism by which the memory
region is *discovered*. It doesn't matter if it's ACPI, DT, a
hypervisor enlightenment, a BAR of a simple PCI device, virtio, or
anything else.

ACPI is one of the *simplest* options for a hypervisor and guest to
implement, and doesn't prevent us from using the same structure in
virtio-rtc. I'm happy enough using ACPI and letting virtio-rtc come
along later.

> virtio has been developed with the painful experience that we keep
> making mistakes, or coming up with new needed features,
> and that maintaining forward and backward compatibility
> becomes a whole lot harder than it seems in the beginning.

Yes. But as you note, this shared memory structure is a userspace ABI
all of its own, so we get to make a completely *different* kind of
mistake :)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)