From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v8 03/10] xen/arm: inflight irqs during migration Date: Thu, 24 Jul 2014 17:48:17 +0100 Message-ID: <1406220497.8706.17.camel@kazak.uk.xensource.com> References: <1405016003-19131-3-git-send-email-stefano.stabellini@eu.citrix.com> <1405601051.31127.9.camel@kazak.uk.xensource.com> <1406129931.21827.24.camel@kazak.uk.xensource.com> <1406220077.8706.13.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thu, 2014-07-24 at 17:45 +0100, Stefano Stabellini wrote: > > Are you sure about the second physical IRQ always hitting on the source > > pCPU though? I'm unclear about where the physical ITARGETSR gets written > > in the scheme you are proposing. > > It gets written right away if there are no inflight irqs. There's no way that something can be pending in the physical GIC at this point? i.e. because it happened since we took the trap? > Otherwise it > gets written when clearing the LRs. That's why we are sure it is going > to hit the old cpu. If the vcpu gets descheduled after EOIing the irq, > that is also fine because Xen is going to clear the LRs on hypervisor > entry. Ian.