>>> On 09.07.15 at 14:53, <george.dun...@eu.citrix.com> wrote: >> The migration is handled in arch_pi_desc_update() which is called >> by vcpu_runstate_change(). > > Well as far as I can tell from looking at the code, > vcpu_runstate_change() will not be called when migrating a vcpu which is > already blocked. > > 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. And I sort of accepted that moving the vCPU between lists when v->processor changes without the vCPU actually running on that pCPU is pretty pointless (and perhaps wasteful, but in any case cluttering more code than necessary). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
