Hi Stefano,
On 10/12/2020 02:30, Stefano Stabellini wrote:
I am also wondering if there is any benefit in calling wait_for_io()
earlier, maybe from try_handle_mmio if IO_RETRY?
wait_for_io() may end up to deschedule the vCPU. I would like to avoid this to
happen in the middle of the I/O emulation because we need to happen it without
lock held at all.
I don't think there are locks involved today, but the deeper in the call stack
the scheduling happens, the more chance we may screw up in the future.
However...
leave_hypervisor_to_guest is very late for that.
... I am not sure what's the problem with that. The IOREQ will be notified of
the pending I/O as soon as try_handle_mmio() put the I/O in the shared page.
If the IOREQ server is running on a different pCPU, then it might be possible
that the I/O has completed before reached leave_hypervisor_to_guest(). In this
case, we would not have to wait for the I/O.
Yeah, I was thinking about that too. Actually it could be faster
this way we end up being lucky.
The reason for moving it earlier would be that by the time
leave_hypervisor_to_guest is called "Xen" has already decided to
continue running this particular vcpu. If we called wait_for_io()
earlier, we would give important information to the scheduler before any
decision is made.
I don't understand this. Xen preemption is voluntary, so the scheduler
is not going to run unless requested.
wait_for_io() is a preemption point. So if you call it, then vCPU may
get descheduled at that point.
Why would we want to do this? What's our benefits here?
Cheers,
--
Julien Grall
