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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 21 Feb 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/02/17 17:49, Stefano Stabellini wrote:
> > On Tue, 21 Feb 2017, Dario Faggioli wrote:
> > > On Tue, 2017-02-21 at 13:46 +0000, George Dunlap wrote:
> > > Oh, actually, if --which I only now realize may be what you are
> > > referring to, since you're talking about "guest burning its credits"--
> > > you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when
> > > the scheduler runs again for whatever reason), you charge to it for all
> > > the time the the pCPU was actually idle/sleeping, well, that may
> > > actually  not break scheduling, or cause disruption to the service of
> > > other vCPUs.... But indeed I'd consider it rather counter intuitive a
> > > behavior.
> > 
> > How can this be safe? There could be no interrupts programmed to wake up
> > the pcpu at all. In fact, I don't think today there would be any, unless
> > we set one up in Xen for the specific purpose of interrupting the pcpu
> > sleep.
> > 
> > I don't know the inner working of the scheduler, but does it always send
> > an interrupt to other pcpu to schedule something?
> 
> You still seem to assume that WFI/WFE is the only way to get a vCPU
> unscheduled. If that was the case it would be utterly wrong because you cannot
> expect a guest to use them.
> 
> > 
> > What if there are 2 vcpu pinned to the same pcpu? This cannot be fair.
> 
> Why wouldn't it be fair? This is the same situation as a guest vCPU not using
> WFI/WFE.

I read your suggestion as trapping WFI in Xen, then, depending on
settings, executing WFI in the Xen trap handler to idle the pcpu. That
doesn't work. But I take you suggested not trapping wfi (remove
HCR_TWI), executing the instruction in guest context. That is what we
used to do in the early days (before a780f750). It should be safe and
possibly even quick. I'll rerun the numbers and let you know.

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