linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: eric.auger@st.com, robin.murphy@arm.com,
	alex.williamson@redhat.com, will.deacon@arm.com, joro@8bytes.org,
	tglx@linutronix.de, jason@lakedaemon.net,
	christoffer.dall@linaro.org,
	linux-arm-kernel@lists.infradead.org, patches@linaro.org,
	linux-kernel@vger.kernel.org, Bharat.Bhushan@freescale.com,
	pranav.sawargaonkar@gmail.com, p.fedin@samsung.com,
	iommu@lists.linux-foundation.org, Jean-Philippe.Brucker@arm.com,
	julien.grall@arm.com
Subject: Re: [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback
Date: Wed, 20 Apr 2016 20:16:37 +0200	[thread overview]
Message-ID: <5717C785.9050809@linaro.org> (raw)
In-Reply-To: <20160420185648.5982deb7@arm.com>

Marc,
On 04/20/2016 07:56 PM, Marc Zyngier wrote:
> On Wed, 20 Apr 2016 14:33:17 +0200
> Eric Auger <eric.auger@linaro.org> wrote:
> 
>> Marc,
>> On 04/20/2016 11:27 AM, Marc Zyngier wrote:
>>> On 19/04/16 18:13, Eric Auger wrote:
>>>> This patch implements the msi_doorbell_info callback in the
>>>> gicv2m driver.
>>>>
>>>> The driver now is able to return its doorbell characteristics
>>>> (base, size, prot). A single doorbell is exposed.
>>>>
>>>> This will allow the msi layer to iommu_map this doorbell when
>>>> requested.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>>
>>>> ---
>>>>
>>>> v7: creation
>>>> ---
>>>>  drivers/irqchip/irq-gic-v2m.c | 32 +++++++++++++++++++++++++++++++-
>>>>  1 file changed, 31 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
>>>> index 28f047c..54690b9 100644
>>>> --- a/drivers/irqchip/irq-gic-v2m.c
>>>> +++ b/drivers/irqchip/irq-gic-v2m.c
>>>> @@ -24,6 +24,8 @@
>>>>  #include <linux/of_pci.h>
>>>>  #include <linux/slab.h>
>>>>  #include <linux/spinlock.h>
>>>> +#include <linux/percpu.h>
>>>> +#include <linux/iommu.h>
>>>>  
>>>>  /*
>>>>  * MSI_TYPER:
>>>> @@ -64,6 +66,7 @@ struct v2m_data {
>>>>  	u32 nr_spis;		/* The number of SPIs for MSIs */
>>>>  	unsigned long *bm;	/* MSI vector bitmap */
>>>>  	u32 flags;		/* v2m flags for specific implementation */
>>>> +	struct irq_chip_msi_doorbell_info doorbell_info;
>>>>  };
>>>>  
>>>>  static void gicv2m_mask_msi_irq(struct irq_data *d)
>>>> @@ -105,6 +108,16 @@ static void gicv2m_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>>>>  		msg->data -= v2m->spi_start;
>>>>  }
>>>>  
>>>> +static const struct irq_chip_msi_doorbell_info *
>>>> +gicv2m_msi_doorbell_info(struct irq_data *data)
>>>> +{
>>>> +	struct v2m_data *v2m = irq_data_get_irq_chip_data(data);
>>>> +
>>>> +	if (!v2m)
>>>> +		return NULL;
>>>
>>> How can this ever be NULL? I think you can drop that test.
>> OK
>>>
>>>> +	return (const struct irq_chip_msi_doorbell_info *)(&v2m->doorbell_info);
>>>
>>> Please don't do that. Use "const" in the functions that are using
>>> irq_chip_msi_doorbell_info, but do not make this "const" here.
>> It definitively compiles without casting so obviously this is not needed
>> but is there any other wrong thing I don't see?
>> we still want this function to return a pointer to a const?
> 
> I don't think we can return a const pointer, because it is obviously
> not (the memory has been kmalloc'ed, and you've written to it, so it is
> not really "read-only").
I see what you are afraid of now and I will remove it; will ask some
compiler guys ;-)

Have a nice evening

Eric

> 
> Maybe I'm being overly zealous, but I've seen compilers taking amazing
> shortcuts when offered a const qualifier...
> 
>>>
>>>> +}
>>>> +
>>>>  static struct irq_chip gicv2m_irq_chip = {
>>>>  	.name			= "GICv2m",
>>>>  	.irq_mask		= irq_chip_mask_parent,
>>>> @@ -112,6 +125,7 @@ static struct irq_chip gicv2m_irq_chip = {
>>>>  	.irq_eoi		= irq_chip_eoi_parent,
>>>>  	.irq_set_affinity	= irq_chip_set_affinity_parent,
>>>>  	.irq_compose_msi_msg	= gicv2m_compose_msi_msg,
>>>> +	.msi_doorbell_info	= gicv2m_msi_doorbell_info,
>>>>  };
>>>>  
>>>>  static int gicv2m_irq_gic_domain_alloc(struct irq_domain *domain,
>>>> @@ -247,6 +261,7 @@ static void gicv2m_teardown(void)
>>>>  
>>>>  	list_for_each_entry_safe(v2m, tmp, &v2m_nodes, entry) {
>>>>  		list_del(&v2m->entry);
>>>> +		free_percpu(v2m->doorbell_info.percpu_doorbells);
>>>>  		kfree(v2m->bm);
>>>>  		iounmap(v2m->base);
>>>>  		of_node_put(to_of_node(v2m->fwnode));
>>>> @@ -299,6 +314,7 @@ static int __init gicv2m_init_one(struct fwnode_handle *fwnode,
>>>>  {
>>>>  	int ret;
>>>>  	struct v2m_data *v2m;
>>>> +	struct irq_chip_msi_doorbell __percpu *doorbell;
>>>>  
>>>>  	v2m = kzalloc(sizeof(struct v2m_data), GFP_KERNEL);
>>>>  	if (!v2m) {
>>>> @@ -311,11 +327,23 @@ static int __init gicv2m_init_one(struct fwnode_handle *fwnode,
>>>>  
>>>>  	memcpy(&v2m->res, res, sizeof(struct resource));
>>>>  
>>>> +	v2m->doorbell_info.percpu_doorbells =
>>>> +		alloc_percpu(struct irq_chip_msi_doorbell);
>>>> +	if (WARN_ON(!v2m->doorbell_info.percpu_doorbells)) {
>>>> +		ret = -ENOMEM;
>>>> +		goto err_free_v2m;
>>>> +	}
>>>> +	doorbell = per_cpu_ptr(v2m->doorbell_info.percpu_doorbells, 0);
>>>> +	doorbell->base = v2m->res.start;
>>>> +	doorbell->size = 4;
>>>> +	doorbell->prot = IOMMU_WRITE;
>>>
>>> You probably need to also have something that says IOMMU_DEVICE or
>>> something similar, because I'm afraid you're getting a memory mapping
>>> here. I've had a quick look at the two other series, but couldn't find
>>> anything that would force the memory attributes.
>> Yes you're right I currently just enforce the direction (which is
>> checked against what VFIO user registered). Do you refer to IOMMU_MMIO,
>> latterly proposed on the ML. In the positive, yes I intend to add it
>> once it gets upstreamed.
> 
> Yeah, Robin's patches should become a dependency here, because there is
> absolutely no guarantee that the device write to the doorbell won't be
> treated a normal cacheable memory, with disastrous effects.
> 
> Thanks,
> 
> 	M.
> 

  reply	other threads:[~2016-04-20 18:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 17:13 [PATCH v7 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes Eric Auger
2016-04-19 17:13 ` [PATCH v7 1/8] genirq/msi: Add a new MSI_FLAG_IRQ_REMAPPING flag Eric Auger
2016-04-22 11:02   ` Robin Murphy
2016-04-22 12:25     ` Eric Auger
2016-04-22 15:39       ` Thomas Gleixner
2016-04-19 17:13 ` [PATCH v7 2/8] irqchip/gic-v3-its: ITS advertises MSI_FLAG_IRQ_REMAPPING Eric Auger
2016-04-19 17:13 ` [PATCH v7 3/8] genirq/msi: export msi_get_domain_info Eric Auger
2016-04-19 17:13 ` [PATCH v7 4/8] genirq/msi: msi_compose wrapper Eric Auger
2016-04-19 17:13 ` [PATCH v7 5/8] genirq/irq: introduce msi_doorbell's structs and related callback Eric Auger
2016-04-20  9:16   ` Marc Zyngier
2016-04-20  9:36     ` Eric Auger
2016-04-19 17:13 ` [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback Eric Auger
2016-04-20  9:27   ` Marc Zyngier
2016-04-20 12:33     ` Eric Auger
2016-04-20 17:56       ` Marc Zyngier
2016-04-20 18:16         ` Eric Auger [this message]
2016-04-19 17:13 ` [PATCH v7 7/8] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs Eric Auger
2016-04-19 18:04   ` kbuild test robot
2016-04-20  7:47     ` Eric Auger
2016-04-26  1:24       ` [lkp] " Ye Xiaolong
2016-04-26 16:43         ` Eric Auger
2016-04-19 17:13 ` [PATCH v7 8/8] genirq/msi: use the MSI doorbell's IOVA when requested Eric Auger
2016-04-20  9:44   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5717C785.9050809@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=Jean-Philippe.Brucker@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@st.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jason@lakedaemon.net \
    --cc=joro@8bytes.org \
    --cc=julien.grall@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=p.fedin@samsung.com \
    --cc=patches@linaro.org \
    --cc=pranav.sawargaonkar@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).