On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wrote:
The hypercalls we are talking of are synchronous ones. They are running
in the context of the vcpu doing the call (like a syscall from userland is
running in the process context).
(so time actually passes from the guest's pov?)
The hypervisor will return to guest context from time to time by modifying
the registers such that the guest will do the hypercall again with different
input values for the hypervisor, resulting in a proper continuation of the
hypercall processing.
Eeeuw.. that's pretty terrible. And changing this isn't in the cards,
like at all?
That is, why isn't this whole thing written like:
for (;;) {
ret = hypercall(foo);
if (ret == -EAGAIN) {
cond_resched();
continue;
}
break;
}
It is an awful interface and I agree that switching to full preemption in
dom0 seems to be the route which we should try to take.
Well, I would very strongly suggest the route to take is to scrap the
whole thing and invest in doing something saner so we don't have to jump
through hoops like this.
This is quite possibly the worst possible interface for this Xen could
have come up with -- awards material for sure.
The downside would be that some workloads might see worse performance
due to backend I/O handling might get preempted.
Is that an actual concern? Mark this a legaxy inteface and anybody who
wants to get away from it updates.
Just thinking - can full preemption be enabled per process?
Nope, that's a system wide thing. Preemption is something that's driven
by the requirements of the tasks that preempt, not something by the
tasks that get preempted.
Andy's idea of having that thing intercepted as an exception (EXTABLE
like) and relocating the IP to a place that does cond_resched() before
going back is an option.. gross, but possibly better, dunno.
Quite the mess indeed :/
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature