From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paul Mackerras <paulus@ozlabs.org>
Subject: Re: [PATCH v2 04/16] KVM: PPC: Book3S HV: XIVE: add a control to
 initialize a source
Date: Tue, 26 Feb 2019 15:25:15 +1100
Message-ID: <20190226042515.GB28015@blackberry>
References: <20190222112840.25000-1-clg@kaod.org>
 <20190222112840.25000-5-clg@kaod.org>
 <20190225021012.GH7668@umbus.fritz.box>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org,
 =?iso-8859-1?Q?C=E9dric?= Le Goater <clg@kaod.org>,
 linuxppc-dev@lists.ozlabs.org
To: David Gibson <david@gibson.dropbear.id.au>
Return-path: <linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org>
Content-Disposition: inline
In-Reply-To: <20190225021012.GH7668@umbus.fritz.box>
List-Unsubscribe: <https://lists.ozlabs.org/options/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>
List-Archive: <http://lists.ozlabs.org/pipermail/linuxppc-dev/>
List-Post: <mailto:linuxppc-dev@lists.ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>
List-Subscribe: <https://lists.ozlabs.org/listinfo/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>
Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org
Sender: "Linuxppc-dev"
 <linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org>
List-Id: kvm.vger.kernel.org

On Mon, Feb 25, 2019 at 01:10:12PM +1100, David Gibson wrote:
> On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> > +	/*
> > +	 * If the source doesn't already have an IPI, allocate
> > +	 * one and get the corresponding data
> > +	 */
> > +	if (!state->ipi_number) {
> > +		state->ipi_number = xive_native_alloc_irq();
> > +		if (state->ipi_number == 0) {
> > +			pr_err("Failed to allocate IRQ !\n");
> > +			return -ENXIO;
> > +		}
> > +		xive_native_populate_irq_data(state->ipi_number,
> > +					      &state->ipi_data);
> > +		pr_debug("%s allocated hw_irq=0x%x for irq=0x%lx\n", __func__,
> > +			 state->ipi_number, irq);
> > +	}
> > +
> > +	arch_spin_lock(&sb->lock);
> 
> Why the direct call to arch_spin_lock() rather than just spin_lock()?

He's sharing data structures with the xics-on-xive code, and that code
has a real-mode variant, and in real mode we don't want to risk
invoking lockdep code.  Hence sb->lock is an arch_spinlock_t, and he
has to use arch_spin_lock() on it.

Paul.