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

[David Woodhouse]

On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > > > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > > > > Do you want to just help complete virtio-rtc then? Would be 
> > > > > > > easier than
> > > > > > > trying to keep two specs in sync.
> > > > > > 
> > > > > > The ACPI version is much more lightweight and doesn't take up a
> > > > > > valuable PCI slot#. (I know, you can do virtio without PCI but 
> > > > > > that's
> > > > > > complex in other ways).
> > > > > > 
> > > > > 
> > > > > Hmm, should we support virtio over ACPI? Just asking.
> > > > 
> > > > Given that we support virtio DT bindings, and the ACPI "PRP0001" device
> > > > exists with a DSM method which literally returns DT properties,
> > > > including such properties as "compatible=virtio,mmio" ... do we
> > > > already?
> > > > 
> > > > 
> > > 
> > > In a sense, but you are saying that is too complex?
> > > Can you elaborate?
> > 
> > No, I think it's fine. I encourage the use of the PRP0001 device to
> > expose DT devices through ACPI. I was just reminding you of its
> > existence.
> 
> Confused. You said "I know, you can do virtio without PCI but that's
> complex in other ways" as the explanation why you are doing a custom
> protocol.

Ah, apologies, I wasn't thinking that far back in the conversation.

If we wanted to support virtio over ACPI, I think PRP0001 can be made
to work and isn't too complex (even though it probably doesn't yet work
out of the box).

But for the VMCLOCK thing, yes, the simple ACPI device is a lot simpler
than virtio-rtc and much more attractive.

Even if the virtio-rtc specification were official today, and I was
able to expose it via PCI, I probably wouldn't do it that way. There's
just far more in virtio-rtc than we need; the simple shared memory
region is perfectly sufficient for most needs, and especially ours.

I have reworked
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
to take your other feedback into account.

It's now more flexible about the size handling, and explicitly checking
that specific fields are present before using them. 

I think I'm going to add a method on the ACPI device to enable the
precise clock information. I haven't done that in the driver yet; it
still just consumes the precise clock information if it happens to be
present already. The enable method can be added in a compatible fashion
(the failure mode is that guests which don't invoke this method when
the hypervisor needs them to will see only the disruption signal and
not precise time).

For the HID I'm going to use AMZNVCLK. I had used QEMUVCLK in the QEMU
patches, but I'll change that to use AMZNVCLK too when I repost the
QEMU patch.

smime.p7s
Description: S/MIME cryptographic signature