On Thu, 25 Jul 2024 14:50:50 +0100
David Woodhouse [off-list ref] wrote:

On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:

quoted

On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:  

quoted

On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:  

quoted

On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:  

quoted

On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:  

quoted

On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:  

quoted

quoted

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.

That doesn't fit with ACPI _HID definitions.
Second set 4 characters need to be hex digits as this is an
ACPI style ID (which I assume this is given AMZN is a valid
vendor ID.  6.1.5 in ACPI v6.5

Maybe I'm missing something...

J