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: <bb6d446076ed577337db1f8795b11599dfff1d1f.camel@infradead.org>
Date: Fri, 26 Jul 2024 13:51:26 +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 Fri, 2024-07-26 at 08:47 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> > That's great. You don't even need it to be per-vCPU if you let the
> > hypervisor write directly to the single physical location that's mapped
> > to userspace. It can do that before it even starts *running* the vCPUs
> > after migration. It's a whole lot simpler. 
> 
> It *seems* simpler, until you realize that there is no way
> to change anything in the interface, there is no negotiation
> between hypervisor and userspace. If I learned anything at all
> in tens of years working on software, it's that it is
> never done. So let's have userspace talk to the kernel
> and have kernel talk to the devices, please. There's
> no compelling reason to have this bypass here.

Thanks for the useful feedback. As you see, I've incorporated most of
it into the v2 post a few minutes ago.

On this particular topic we disagree. I absolutely don't want to take
dependencies on kernel code, on virtio, or on the cross-platform
assumption (even if it's true) that a device can raise an interrupt and
guarantee that no userspace code will run before that interrupt is
handled.

Using virtio does allow for some negotiation — for handling differences
in page sizes, and enabling the timekeeping only on demand. That's
great, but the structure is still an ABI in its own right, and we know
how to do those.

We'll ship the ACPI version, and I look forward to incorporating it
into virtio-rtc too.

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