Linux IOMMU Development
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Robin Murphy <robin.murphy@arm.com>, joro@8bytes.org
Cc: iommu@lists.linux-foundation.org, will.deacon@arm.com,
	marc.zyngier@arm.com, gabriele.paoloni@huawei.com,
	john.garry@huawei.com, shameerali.kolothum.thodi@huawei.com,
	Alex Williamson <alex.williamson@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 1/3] iommu: Disambiguate MSI region types
Date: Mon, 13 Mar 2017 15:58:31 +0100	[thread overview]
Message-ID: <f4522eff-4cdc-2dd5-dcb1-afd2d15ecd02@redhat.com> (raw)
In-Reply-To: <5db5c64f-05e4-6167-3c29-b1607a794ce3@arm.com>

Hi Robin,

On 13/03/2017 15:24, Robin Murphy wrote:
> On 13/03/17 13:08, Auger Eric wrote:
>> Hi Robin,
>>
>> On 09/03/2017 20:50, Robin Murphy wrote:
>>> Whilst it doesn't matter much to VFIO at the moment, when parsing
>>> reserved regions on the host side we really needs to be able to tell
>> s/needs/need
> 
> Oops!
> 
>>> the difference between the software-reserved region used to map MSIs
>>> translated by an IOMMU, and hardware regions for which the write might
>>> never even reach the IOMMU. In particular, ARM systems assume the former
>>> topology, but may need to cope with the latter as well, which will
>>> require rather different handling in the iommu-dma layer.
>>>
>>> For clarity, rename the software-managed type to IOMMU_RESV_SW_MSI, use
>>> IOMMU_RESV_MSI to describe the hardware type, and document everything a
>>> little bit. Since the x86 MSI remapping hardware falls squarely under
>>> this meaning of IOMMU_RESV_MSI, apply that type to their regions as well,
>>> so that we tell a consistent story to userspace across platforms (and
>>> have future consistency if those drivers start migrating to iommu-dma).
>>>
>>> Fixes: d30ddcaa7b02 ("iommu: Add a new type field in iommu_resv_region")
>> does it really fall under the category of fix here?
> 
> I was somewhat on the fence about that, as the rationale above does tend
> towards future new functionality, but the primary effect of this patch
> alone is an ABI-visible change for x86 in terms of "expose the MSI
> region as an MSI region". IMO it would be better to get that in before
> said ABI gets baked into a kernel release, hence leaning towards the
> "fix" side of things. I'm happy to rewrite the commit message in reverse
> order (i.e. "clean up this ABI inconsistency, with these additional
> benefits") if it would be clearer.
OK no worries. I understand what you meant.
> 
>>> CC: Eric Auger <eric.auger@redhat.com>
>>> CC: Alex Williamson <alex.williamson@redhat.com>
>>> CC: David Woodhouse <dwmw2@infradead.org>
>>> CC: kvm@vger.kernel.org
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>> ---
>>>  drivers/iommu/amd_iommu.c       | 2 +-
>>>  drivers/iommu/arm-smmu-v3.c     | 2 +-
>>>  drivers/iommu/arm-smmu.c        | 2 +-
>>>  drivers/iommu/intel-iommu.c     | 2 +-
>>>  drivers/iommu/iommu.c           | 1 +
>>>  drivers/vfio/vfio_iommu_type1.c | 2 +-
>>>  include/linux/iommu.h           | 5 +++++
>>>  7 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
>>> index 98940d1392cb..b17536d6e69b 100644
>>> --- a/drivers/iommu/amd_iommu.c
>>> +++ b/drivers/iommu/amd_iommu.c
>>> @@ -3202,7 +3202,7 @@ static void amd_iommu_get_resv_regions(struct device *dev,
>>>  
>>>  	region = iommu_alloc_resv_region(MSI_RANGE_START,
>>>  					 MSI_RANGE_END - MSI_RANGE_START + 1,
>>> -					 0, IOMMU_RESV_RESERVED);
>>> +					 0, IOMMU_RESV_MSI);
>>>  	if (!region)
>>>  		return;
>>>  	list_add_tail(&region->list, head);
>>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>>> index 5806a6acc94e..591bb96047c9 100644
>>> --- a/drivers/iommu/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm-smmu-v3.c
>>> @@ -1888,7 +1888,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
>>>  	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>>>  
>>>  	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
>>> -					 prot, IOMMU_RESV_MSI);
>>> +					 prot, IOMMU_RESV_SW_MSI);
>>>  	if (!region)
>>>  		return;
>>>  
>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>> index abf6496843a6..b493c99e17f7 100644
>>> --- a/drivers/iommu/arm-smmu.c
>>> +++ b/drivers/iommu/arm-smmu.c
>>> @@ -1608,7 +1608,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
>>>  	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>>>  
>>>  	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
>>> -					 prot, IOMMU_RESV_MSI);
>>> +					 prot, IOMMU_RESV_SW_MSI);
>>>  	if (!region)
>>>  		return;
>>>  
>>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>>> index 238ad3447712..f1611fd6f5b0 100644
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -5249,7 +5249,7 @@ static void intel_iommu_get_resv_regions(struct device *device,
>>>  
>>>  	reg = iommu_alloc_resv_region(IOAPIC_RANGE_START,
>>>  				      IOAPIC_RANGE_END - IOAPIC_RANGE_START + 1,
>>> -				      0, IOMMU_RESV_RESERVED);
>>> +				      0, IOMMU_RESV_MSI);
>>>  	if (!reg)
>>>  		return;
>>>  	list_add_tail(&reg->list, head);
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 8ea14f41a979..7dbc05f10d5a 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -72,6 +72,7 @@ static const char * const iommu_group_resv_type_string[] = {
>>>  	[IOMMU_RESV_DIRECT]	= "direct",
>>>  	[IOMMU_RESV_RESERVED]	= "reserved",
>>>  	[IOMMU_RESV_MSI]	= "msi",
>>> +	[IOMMU_RESV_SW_MSI]	= "msi",
> 
> As a side note, is it intentional that the values are bitfields, in
> other words, is it ever going to make sense to combine them? The fact
> that we use them directly to index an array here suggests not, and that
> we might be better off with a plain enum. Otherwise, another possibility
> would be to keep a single "MSI" type flag and add a separate
> "software-managed" flag alongside it, with a corresponding tweak to
> iommu_group_show_resv_regions(). Does anyone have a strong opinion
> either way?

Originally this stems from "IOMMU_NOMAP" flavored define but I think
this should be transformed into an enum instead.

Thanks

Eric
> 
>>>  };
>>>  
>>>  #define IOMMU_GROUP_ATTR(_name, _mode, _show, _store)		\
>>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>>> index c26fa1f3ed86..e32abdebd2df 100644
>>> --- a/drivers/vfio/vfio_iommu_type1.c
>>> +++ b/drivers/vfio/vfio_iommu_type1.c
>>> @@ -1192,7 +1192,7 @@ static bool vfio_iommu_has_resv_msi(struct iommu_group *group,
>> Maybe we should change the name of the function into
>> vfio_iommu_has_resv_sw_msi?
> 
> Good idea, will do.
> 
>> Besides
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> 
> Thanks!
> 
> Robin.
> 
>>
>> Thanks
>>
>> Eric
>>
>>
>>>  	INIT_LIST_HEAD(&group_resv_regions);
>>>  	iommu_get_group_resv_regions(group, &group_resv_regions);
>>>  	list_for_each_entry(region, &group_resv_regions, list) {
>>> -		if (region->type & IOMMU_RESV_MSI) {
>>> +		if (region->type & IOMMU_RESV_SW_MSI) {
>>>  			*base = region->start;
>>>  			ret = true;
>>>  			goto out;
>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>>> index 6a6de187ddc0..fad2c4913be4 100644
>>> --- a/include/linux/iommu.h
>>> +++ b/include/linux/iommu.h
>>> @@ -125,9 +125,14 @@ enum iommu_attr {
>>>  };
>>>  
>>>  /* These are the possible reserved region types */
>>> +/* Memory regions which must have 1:1 translations present at all times */
>>>  #define IOMMU_RESV_DIRECT	(1 << 0)
>>> +/* Arbitrary "never map this or give it to a device" address ranges */
>>>  #define IOMMU_RESV_RESERVED	(1 << 1)
>>> +/* Hardware MSI region (untranslated) */
>>>  #define IOMMU_RESV_MSI		(1 << 2)
>>> +/* Software-managed MSI translation window */
>>> +#define IOMMU_RESV_SW_MSI	(1 << 3)
>>>  
>>>  /**
>>>   * struct iommu_resv_region - descriptor for a reserved memory region
>>>
> 

      reply	other threads:[~2017-03-13 14:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 19:50 [PATCH 1/3] iommu: Disambiguate MSI region types Robin Murphy
     [not found] ` <1b012c7e82ccef1a34be38d81e82e74f129dfedc.1489088954.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-03-09 19:50   ` [PATCH 2/3] iommu/dma: Don't reserve PCI I/O windows Robin Murphy
     [not found]     ` <65d11acdff57a3f448df6c90da338750ce7733e9.1489088954.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-03-13 13:07       ` Auger Eric
2017-03-09 19:50   ` [PATCH 3/3] iommu/dma: Handle IOMMU API reserved regions Robin Murphy
     [not found]     ` <ccb0f5ef6822c760c253038e27e55752210b754b.1489088954.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-03-10  9:03       ` Shameerali Kolothum Thodi
2017-03-13 13:07       ` Auger Eric
     [not found]         ` <de0cbfa3-473a-e761-6ffa-aee5cf729c0f-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-13 13:55           ` Robin Murphy
2017-03-13 11:41   ` [PATCH 1/3] iommu: Disambiguate MSI region types Shameerali Kolothum Thodi
2017-03-13 13:08 ` Auger Eric
     [not found]   ` <a4b012cc-e95d-37af-374a-f06661798168-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-13 14:24     ` Robin Murphy
2017-03-13 14:58       ` Auger Eric [this message]

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=f4522eff-4cdc-2dd5-dcb1-afd2d15ecd02@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=gabriele.paoloni@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=john.garry@huawei.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --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