Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2015-07-09 at 14:44 +0100, Jan Beulich wrote:
> >>> On 09.07.15 at 14:53, <george.dunlap@xxxxxxxxxxxxx> wrote:

> > Consider the following scenario:
> > - v1 blocks on pcpu 0.
> >  - vcpu_runstate_change() will do everything necessary for v1 on p0.
> > - The scheduler does load balancing and moves v1 to p1, calling
> > vcpu_migrate().  Because the vcpu is still blocked,
> > vcpu_runstate_change() is not called.
> > - A device interrupt is generated.
> > 
> > What happens to the interrupt?  Does everything still work properly, or
> > will the device wake-up interrupt go to the wrong pcpu (p0 rather than p1)?
> 
> I think much of this was discussed before, since I also disliked the
> hooking into vcpu_runstate_change(). What I remember having
> been told is that it really only matters which pCPU's list a vCPU is
> on, not what v->processor says. 
>
Right.

But, as far as I could understand from the patches I've seen, a vcpu
ends up in a list when it blocks, and when it blocks there will be a
context switch, and hence we can deal with the queueing during the the
context switch itself (which is, in part, an arch specific operation
already).

What am I missing?

Maybe (looking at vmx_pi_desc_update() in patch 14), something that is
right now dealt with by means of RUNSTATE_offline? What (if yes)? Can
(if yes) it be explained in some "non rusntate"-based way, so we can
judge whether that could also be achieved differently than by actually
hooking in vcpu_runstate_change()?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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