Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter

[Julien Grall <julien.grall@xxxxxxx>]

Hi Dario,

On 20/02/17 19:20, Dario Faggioli wrote:
> On Mon, 2017-02-20 at 18:53 +0000, Julien Grall wrote:
> > On 20/02/17 18:47, Stefano Stabellini wrote:
> > > This is a good question, I have already answered: I think it would
> > > break
> > > the scheduler. Dario confirmed it in his reply
> > > (1487382463.6732.146.camel@xxxxxxxxxx).
> > I don't think it will break the scheduler, we are trapping WFI/WFE
> > to
> > take advantage of the quiescence of the guest. If we don't do that,
> > the
> > guest will just waste his slot.
> Err... Wait... WF* basically puts a _pCPU_ to sleep until something
> happens (interrupt or event). This is not something we let a guest
> _vCPU_ do!
>
> E.g., if vCPU x of domain A wants to go idle with a WFI/WFE, but the
> host is overbooked and currently really busy, Xen wants to run some
> other vCPU (of either the same of another domain).
>
> That's actually the whole point of virtualization, and the reason why
> overbooking an host with more vCPUs (from multiple guests) than it has
> pCPUs works at all. If we start letting guests put the host's pCPUs to
> sleep, not only the scheduler, but many things would break, IMO!
I am not speaking about general case but when you get 1 vCPU pinned to 1 
pCPU (I think this is Stefano use case). No other vCPU will run on this 
pCPU. So it would be fine to let the guest do the WFI.
If you run multiple vCPU in the same pCPU you would have a bigger 
interrupt latency. And blocked the vCPU or yield will likely have the 
same number unless you know the interrupt will come right now. But in 
that case, using WFI in the guest may not have been the right things to do.
I have heard use case where people wants to disable the scheduler (e.g a 
nop scheduler) because they know only 1 vCPU will ever run on the pCPU. 
This is exactly the use case I am thinking about.
> > Even if the WFI is done by the guest, you will receive the scheduler
> > interrupt in Xen and that's fine. Did I miss anything?
> Maybe it's me that am missing what you actually mean here.
>
> What do you mean with "you will receive the scheduler interrupt"? Right
> now, HLT in guest means block in Xen, which makes the scheduler run and
> decide whether the pCPU should stay idle, or run someone else. I'd say
> that no good can come from having HTL in guest automatically meaning
> also on the pCPU.
>
> So, I'm not sure what we're talking about, but what I'm quite sure is
> that we don't want a guest to be able to decide when and until what
> time/event, a pCPU goes idle.
Well, if the guest is not using the WFI/WFE at all you would need an 
interrupt from the scheduler to get it running. So here it is similar, 
the scheduler would have setup a timer and the processor will awake when 
receiving the timer interrupt to enter in the hypervisor.
So, yes in fine the guest will waste its slot. But this is what would 
have happen if the guest is not using any of the WFI/WFE instructions.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel