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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
