mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Don Dutile <ddutile@redhat.com>,
	eric.auger.pro@gmail.com, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, robin.murphy@arm.com,
	alex.williamson@redhat.com, will.deacon@arm.com, joro@8bytes.org,
	tglx@linutronix.de, jason@lakedaemon.net,
	linux-arm-kernel@lists.infradead.org
Cc: kvm@vger.kernel.org, drjones@redhat.com,
	linux-kernel@vger.kernel.org, pranav.sawargaonkar@gmail.com,
	iommu@lists.linux-foundation.org, punit.agrawal@arm.com,
	diana.craciun@nxp.com
Subject: Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
Date: Mon, 12 Dec 2016 09:12:56 +0100	[thread overview]
Message-ID: <ca2a723f-6880-b3af-eef6-5482272a98fb@redhat.com> (raw)
In-Reply-To: <584CB481.3040902@redhat.com>

Hi Don,

On 11/12/2016 03:05, Don Dutile wrote:
> On 12/08/2016 04:36 AM, Auger Eric wrote:
>> Hi,
>>
>> On 15/11/2016 14:09, Eric Auger wrote:
>>> Following LPC discussions, we now report reserved regions through
>>> iommu-group sysfs reserved_regions attribute file.
>>
>>
>> While I am respinning this series into v4, here is a tentative summary
>> of technical topics for which no consensus was reached at this point.
>>
>> 1) Shall we report the usable IOVA range instead of reserved IOVA
>>     ranges. Not discussed at/after LPC.
>>     x I currently report reserved regions. Alex expressed the need to
>>       report the full usable IOVA range instead (x86 min-max range
>>       minus MSI APIC window). I think this is meaningful for ARM
>>       too where arm-smmu might not support the full 64b range.
>>     x Any objection we report the usable IOVA regions instead?
>>
>> 2) Shall the kernel check collision with MSI window* when userspace
>>     calls VFIO_IOMMU_MAP_DMA?
>>     Joerg/Will No; Alex yes
>>     *for IOVA regions consumed downstream to the IOMMU: everyone says NO
>>
>> 3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no
> Um, I'm missing context, but the only thing I recall saying no to wrt RMRR
> is that _any_ device that has an RMRR cannot be assigned to a guest.
Yes that was my understanding
> Or, are you saying, RMRR's should be exposed in the guest os?  if so, then
> you have my 'no' there.
> 
>>     My current series does not expose them in iommu group sysfs.
>>     I understand we can expose the RMRR regions in the iomm group sysfs
>>     without necessarily supporting RMRR requiring device assignment.
> This sentence doesn't make sense to me.
> Can you try re-wording it?
> I can't tell what RMRR has to do w/device assignment, other than what I
> said above.
> Exposing RMRR's in sysfs is not an issue in general.
Sorry for the confusion. I Meant we can expose RMRR regions as part of
the reserved regions through the iommu group sysfs API without
supporting device assignment of devices that has RMRR.

Hope it clarifies

Eric
> 
>>     We can also add this support later.
>>
>> Thanks
>>
>> Eric
>>
>>
>>>
>>> Reserved regions are populated through the IOMMU get_resv_region
>>> callback
>>> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
>>> arm-smmu.
>>>
>>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>>> IOMMU_RESV_NOMAP reserved region.
>>>
>>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
>>> 1MB large) and the PCI host bridge windows.
>>>
>>> The series integrates a not officially posted patch from Robin:
>>> "iommu/dma: Allow MSI-only cookies".
>>>
>>> This series currently does not address IRQ safety assessment.
>>>
>>> Best Regards
>>>
>>> Eric
>>>
>>> Git: complete series available at
>>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>>
>>> History:
>>> RFC v2 -> v3:
>>> - switch to an iommu-group sysfs API
>>> - use new dummy allocator provided by Robin
>>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>>>    the reserved regions
>>> - at the moment ARM MSI base address/size is left unchanged compared
>>>    to v2
>>> - we currently report reserved regions and not usable IOVA regions as
>>>    requested by Alex
>>>
>>> RFC v1 -> v2:
>>> - fix intel_add_reserved_regions
>>> - add mutex lock/unlock in vfio_iommu_type1
>>>
>>>
>>> Eric Auger (10):
>>>    iommu/dma: Allow MSI-only cookies
>>>    iommu: Rename iommu_dm_regions into iommu_resv_regions
>>>    iommu: Add new reserved IOMMU attributes
>>>    iommu: iommu_alloc_resv_region
>>>    iommu: Do not map reserved regions
>>>    iommu: iommu_get_group_resv_regions
>>>    iommu: Implement reserved_regions iommu-group sysfs file
>>>    iommu/vt-d: Implement reserved region get/put callbacks
>>>    iommu/arm-smmu: Implement reserved region get/put callbacks
>>>    vfio/type1: Get MSI cookie
>>>
>>>   drivers/iommu/amd_iommu.c       |  20 +++---
>>>   drivers/iommu/arm-smmu.c        |  52 +++++++++++++++
>>>   drivers/iommu/dma-iommu.c       | 116
>>> ++++++++++++++++++++++++++-------
>>>   drivers/iommu/intel-iommu.c     |  50 ++++++++++----
>>>   drivers/iommu/iommu.c           | 141
>>> ++++++++++++++++++++++++++++++++++++----
>>>   drivers/vfio/vfio_iommu_type1.c |  26 ++++++++
>>>   include/linux/dma-iommu.h       |   7 ++
>>>   include/linux/iommu.h           |  49 ++++++++++----
>>>   8 files changed, 391 insertions(+), 70 deletions(-)
>>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2016-12-12  8:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 13:09 Eric Auger
2016-11-15 13:09 ` [RFC v3 01/10] iommu/dma: Allow MSI-only cookies Eric Auger
2016-11-15 13:09 ` [RFC v3 02/10] iommu: Rename iommu_dm_regions into iommu_resv_regions Eric Auger
2016-12-06 17:30   ` Robin Murphy
2016-11-15 13:09 ` [RFC v3 03/10] iommu: Add new reserved IOMMU attributes Eric Auger
2016-12-06 17:28   ` Robin Murphy
2016-11-15 13:09 ` [RFC v3 04/10] iommu: iommu_alloc_resv_region Eric Auger
2016-11-29 16:11   ` Joerg Roedel
2016-11-30  9:41     ` Auger Eric
2016-12-06 17:30   ` Robin Murphy
2016-11-15 13:09 ` [RFC v3 05/10] iommu: Do not map reserved regions Eric Auger
2016-12-06 17:36   ` Robin Murphy
2016-12-07 15:15     ` Auger Eric
2016-11-15 13:09 ` [RFC v3 06/10] iommu: iommu_get_group_resv_regions Eric Auger
2016-12-06 18:13   ` Robin Murphy
2016-12-07 15:13     ` Auger Eric
2016-11-15 13:09 ` [RFC v3 07/10] iommu: Implement reserved_regions iommu-group sysfs file Eric Auger
2016-11-15 13:09 ` [RFC v3 08/10] iommu/vt-d: Implement reserved region get/put callbacks Eric Auger
2016-11-15 13:09 ` [RFC v3 09/10] iommu/arm-smmu: " Eric Auger
2016-12-06 18:55   ` Robin Murphy
2016-12-07 15:02     ` Auger Eric
2016-12-07 18:24       ` Robin Murphy
2016-12-08  7:57         ` Auger Eric
2016-11-15 13:09 ` [RFC v3 10/10] vfio/type1: Get MSI cookie Eric Auger
2016-11-18  5:34 ` [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions Bharat Bhushan
2016-11-18  8:33   ` Auger Eric
2016-11-30  9:49 ` Auger Eric
2016-11-30 10:04   ` Ganapatrao Kulkarni
2016-11-30 10:14     ` Auger Eric
2016-11-30 10:52       ` Ganapatrao Kulkarni
2016-11-30 13:57         ` Robin Murphy
2016-11-30 10:37   ` Will Deacon
2016-11-30 14:08     ` Auger Eric
2016-11-30 14:41       ` Robin Murphy
2016-12-07 18:52       ` Shanker Donthineni
2016-12-08  7:34         ` Auger Eric
2016-12-08  3:56 ` Bharat Bhushan
2016-12-08  9:36 ` Auger Eric
2016-12-08 13:14   ` Robin Murphy
2016-12-08 13:36     ` Auger Eric
2016-12-08 15:46       ` Robin Murphy
2016-12-08 17:01     ` Alex Williamson
2016-12-08 18:42       ` Robin Murphy
2016-12-11  2:05   ` Don Dutile
2016-12-12  8:12     ` 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=ca2a723f-6880-b3af-eef6-5482272a98fb@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=ddutile@redhat.com \
    --cc=diana.craciun@nxp.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jason@lakedaemon.net \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=pranav.sawargaonkar@gmail.com \
    --cc=punit.agrawal@arm.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

Powered by JetHome