On Fri, 2024-07-26 at 09:04 -0400, Michael S. Tsirkin wrote:

On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:

quoted

On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:

quoted

On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:

quoted

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.

Maybe it doesn't, at that. E.g. virtio does a copy, acpi doesn't?
I'll ponder compatibility over the weekend.

For clarity, I think I've ditched the idea of a poor-man's negotiation
through invoking an ACPI method to enable the timekeeping info.

I think we're better off waiting for virtio, to enable that kind of
thing.

The guest gets what the hypervisor is prepared to offer "for free".

That isn't a one-way door; we *can* add an optional ACPI method later
if we really want to. But I'm generally OK with "use virtio if you want
that".