On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote: > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote: > > 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
