From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH for-4.6 3/4] xen/arm: vgic: notice if the vIRQ is not allocated when the guest enable it Date: Wed, 14 Jan 2015 12:28:25 +0000 Message-ID: <1421238505.19103.250.camel@citrix.com> References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org> <1418395392-30460-4-git-send-email-julien.grall@linaro.org> <1421164500.19103.132.camel@citrix.com> <54B5810E.2030203@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YBN3m-00080s-8E for xen-devel@lists.xenproject.org; Wed, 14 Jan 2015 12:28:30 +0000 In-Reply-To: <54B5810E.2030203@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org, parth.dixit@linaro.org, christoffer.dall@linaro.org List-Id: xen-devel@lists.xenproject.org On Tue, 2015-01-13 at 20:33 +0000, Julien Grall wrote: > Hi Ian, > > On 13/01/15 15:55, Ian Campbell wrote: > > On Fri, 2014-12-12 at 14:43 +0000, Julien Grall wrote: > >> This help for guest interrupts debugging. If the vIRQ is not allocate, > >> this means that nothing is wired to it. > > > > Should we short circuit the rest of the enable operation for this IRQ > > then? i.e. implement such writes as ignored, e.g. not reflect it in > > reads of ISENABLER etc. > > > > What (if anything) does the GIC spec have to say on the subject? > > "A register bit corresponding to an unimplemented interrupt is RAZ/WI." > > The goal of this print was mostly for debugging physical IRQ routed to a > guest. > > I could extend to ignore write to any register that should be RAZ/WI for > this specific interrupt. Since those are the defined semantics I think that is the best thing to do. > But, I will have to think about possible race condition with the > hypercall to route a physical IRQ to the guest (see [1] and [2]). > > The vIRQ is reserved before the physical IRQ is effectively routed. So > a guest may enable the vIRQ before this time lapse. Though, the patch > [2] protected for a such case. > > Not sure if we should take care of a such case. I don't think so, that routing hypercall ought to be happening strictly before any hotplug event visible to the guest causes it to think there is a device (vacuously true for coldplug too), so the guest should have no expectation of being able to do anything with the irq in question. Ian.