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.
<<attachment: smime.p7s>>
