From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH v4 16/16] xen/arm: add SGI handling for GICv3
Date: Mon, 2 Jun 2014 17:13:39 +0100
Message-ID: <1401725619.8841.12.camel@kazak.uk.xensource.com>
References: <1401100009-7326-1-git-send-email-vijay.kilari@gmail.com>
	<1401100009-7326-17-git-send-email-vijay.kilari@gmail.com>
	<alpine.DEB.2.02.1406021650480.4779@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <alpine.DEB.2.02.1406021650480.4779@kaball.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: vijay.kilari@gmail.com, Prasun.Kapoor@caviumnetworks.com, Vijaya Kumar K <vijaya.kumar@caviumnetworks.com>, julien.grall@linaro.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Mon, 2014-06-02 at 17:05 +0100, Stefano Stabellini wrote:
> > +static int vgicv3_to_sgi(struct vcpu *v, register_t sgir)
> > +{
> > +    int virq;
> > +    int irqmode;
> > +    unsigned long vcpu_mask = 0;
> > +
> > +    irqmode = (sgir >> ICH_SGI_IRQMODE_SHIFT) & ICH_SGI_IRQMODE_MASK;
> > +    virq = (sgir >> ICH_SGI_IRQ_SHIFT ) & ICH_SGI_IRQ_MASK;
> > +    vcpu_mask = sgir & ICH_SGI_TARGETLIST_MASK;
> > +
> > +    return vgic_to_sgi(v, sgir, irqmode, virq, vcpu_mask);
> > +}
> 
> Given that we are not handling affinity 1, 2 and 3 settings, we should
> add an assert to make sure that they are 0.

Not literally an assert since that would give guests a trivial way to
DoS the system....

Given that we create guest VCPUs with MPIDR's which do not use
AFF{1,2,3} I think we can simply ignore any attempt to SGI those
processors, since they can't exist.

Of course this will mean implementing a 16 VCPU limit somewhere on the
creation side, so we actually do not create VCPUs with higher AFF's
used...

There should of course be a suitable comment both here and there...

Ian.