Re: [PATCH] xen/arm: introduce vwfi parameter

[George Dunlap <george.dunlap@citrix.com>]

On 21/02/17 15:14, Julien Grall wrote:
> Hi George,
> 
> On 21/02/17 13:46, George Dunlap wrote:
>> I think our options look like:
> 
> Thank you for the summary of the options!
> 
>>
>> A.  Don't trap guest WFI at all -- allow it to 'halt' in
>> moderate-power-but-ready-for-interrupt mode.
>>
>> B. Trap guest WFI and block normally.
>>
>> C. Trap guest WFI and poll instead of idling.
>>
>> D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep
>> state (perhaps, for instance, using the WFI instruction).
>>
>> A is safe because the scheduler should already have set a timer to break
>> out of it if necessary.  The only potential issue here is that the guest
>> is burning its credits, meaning that other vcpus with something
>> potentially useful to do aren't being allowed to run; and then later
>> when this vcpu has something useful to do it may be prevented from
>> running because of low credits.  (This may be what Dario means when he
>> says it "breaks scheduling").
>>
>> B, C, and D have the advantage that the guest will not be charged for
>> credits, and other useful work can be done if it's possible.
>>
>> B and C have the disadvantage that the effect will be significantly
>> different under Xen than on real hardware: B will mean it will go into a
>> deep sleep state (and thus not be as responsive as on real hardare); C
>> has the disadvantage that there won't be any significant power savings.
> 
> I'd like to correct one misunderstanding here. Today the idle_loop on
> ARM is doing a WFI. This is not a deep-sleep state, it is fairly quite
> quick to come back. What really cost if the context switch of the state
> of the vCPU during blocking.
> 
> So I think B and D are the same. Or did you expect D to not switch to
> the idle vCPU?
> 
> Note, it is possible to implement more deep-sleep state on ARM either
> via PSCI or platform specific code.

Oh, right; so it sounds a bit as if WFI is ARM's version of x86 HLT.  I
thought it was more special. :-)

Things get a bit tricky because one of the purposes of a hypervisor is
to deal with more advanced hardware so that the guest OS doesn't have
to.  For instance, it would make sense to have simple guest OSes that
only know how to do WFI, and then have Xen have the smarts to know if
and when to go into a deeper sleep state.  So you wouldn't normally want
to have WFI be a hint *not* to go into a deep sleep state, unless you
were sure that nearly all your guest operating systems would know how to
say "actually go ahead into a deep sleep state", and said that by default.

 -George


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