Re: [PATCH V3 15/23] xen/arm: Stick around in leave_hypervisor_to_guest until I/O has completed

[Julien Grall <julien@xxxxxxx>]

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