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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > But for this use case, we only need a memory region that the hypervisor
> > can update. We don't need any of that complexity of gratuitously
> > interrupting all the vCPUs just to ensure that none of them can be
> > running userspace while one of them does an update for itself,
> > potentially translating from one ABI to another. The hypervisor can
> > just update the user-visible memory in place.
> 
> Looks like then your userspace is hypervisor specific, and that's a
> problem because it's a one way street - there is no way for hypervisor
> to know what does userspace need, so no way for hypervisor to know which
> information to provide. No real way to fix bugs.

It's not hypervisor specific, but you're right that as it stands there
is no negotiation of what userspace wants. So the hypervisor provides
what it feels it can provide without significant overhead (which may or
may not include the precise timekeeping, as discussed, but should
always include the disruption signal which is the most important
thing).

The guest *does* know what the hypervisor provides. And when we get to
do this in virtio, we get all the goodness of negotiation as well. The
existence of the simple ACPI model doesn't hurt that at all.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]