Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

Hi Robin, On Friday 11 Nov 2016 14:44:29 Robin Murphy wrote: > On 11/11/16 01:50, Laurent Pinchart wrote: > > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: > >> On 20/10/16 00:36, Magnus Damm wrote: > >>> From: Magnus Damm > >>> > >>> Introduce an alternative

Re: [PATCH 4/5] iommu: Move REQ_ACS_FLAGS out to header and rename

On Thu, Nov 10, 2016 at 01:27:13PM +0100, Joerg Roedel wrote: > On Wed, Oct 26, 2016 at 12:01:34PM -0600, Alex Williamson wrote: > > Allow other parts of the kernel to see which PCI ACS flags the IOMMU > > layer considers necessary for isolation. > > > > Signed-off-by: Alex Williamson

[PATCH RESEND] iommu/iova: Extend cached node lookup condition

When searching for a free IOVA range, we optimise the tree traversal by starting from the cached32_node, instead of the last node, when limit_pfn is equal to dma_32bit_pfn. However, if limit_pfn happens to be smaller, then we'll go ahead and start from the top even though dma_32bit_pfn is still a

[PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong

iommu_dma_init_domain() was originally written under the misconception that dma_32bit_pfn represented some sort of size limit for IOVA domains. Since the truth is almost the exact opposite of that, rework the logic and comments to reflect its real purpose of optimising lookups when allocating from

[PATCH v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()

With the new dma_{map,unmap}_resource() functions added to the DMA API for the benefit of cases like slave DMA, add suitable implementations to the arsenal of our generic layer. Since cache maintenance should not be a concern, these can both be standalone callback implementations without the need

[PATCH v3 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()

With no coherency to worry about, just plug'em straight in. CC: Catalin Marinas CC: Will Deacon Signed-off-by: Robin Murphy --- arch/arm64/mm/dma-mapping.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v2 5/5] iommu/mediatek: Fix M4Uv1 group refcounting

For each subsequent device assigned to the m4u_group after its initial allocation, we need to take an additional reference. Otherwise, the caller of iommu_group_get_for_dev() will inadvertently remove the reference taken by iommu_group_add_device(), and the group will be freed prematurely if any

[PATCH v2 4/5] iommu/mediatek: Fix M4Uv2 group refcounting

For each subsequent device assigned to the m4u_group after its initial allocation, we need to take an additional reference. Otherwise, the caller of iommu_group_get_for_dev() will inadvertently remove the reference taken by iommu_group_add_device(), and the group will be freed prematurely if any

[PATCH v2 2/5] iommu/arm-smmu: Fix group refcounting

When arm_smmu_device_group() finds an existing group due to Stream ID aliasing, it should be taking an additional reference on that group. Otherwise, the caller of iommu_group_get_for_dev() will inadvertently remove the reference taken by iommu_group_add_device(), and the group will be freed

[PATCH v2 3/5] iommu/amd: Fix group refcounting

If acpihid_device_group() finds an existing group for the relevant devid, it should be taking an additional reference on that group. Otherwise, the caller of iommu_group_get_for_dev() will inadvertently remove the reference taken by iommu_group_add_device(), and the group will be freed prematurely

[PATCH v2 1/5] iommu: Allow taking a reference on a group directly

iommu_group_get_for_dev() expects that the IOMMU driver's device_group callback return a group with a reference held for the given device. Whilst allocating a new group is fine, and pci_device_group() correctly handles reusing an existing group, there is no general means for IOMMU drivers doing

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote: > In the original of_iommu_configure design, the thought was that an ops > structure could be IOMMU-instance-specific (hence the later-removed > "priv" member), so I suppose right now it is mostly a hangover from > that. However, it's

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/11/2016 10:50 AM, Alex Williamson wrote: On Fri, 11 Nov 2016 12:19:44 +0100 Joerg Roedel wrote: On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote: In the case of x86, we know that DMA mappings overlapping the MSI doorbells won't be translated correctly,

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Eric, On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote: > Effectively in passthrough use case, the userspace defines the address > space layout and maps guest RAM PA=IOVA to PAs (using > VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI > IOVAs. Userspace does not

Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system > is booted and needs to be accessed unencrypted.  Add support to apply > the proper attributes to the EFI page tables and to the > early_memremap and memremap APIs to

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 11/11/16 15:22, Joerg Roedel wrote: > On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote: >> +struct iommu_fwentry { >> +struct list_head list; >> +struct fwnode_handle *fwnode; >> +const struct iommu_ops *ops; >> +}; > > Is there a reason the iommu_ops need to be

Re: Summary of LPC guest MSI discussion in Santa Fe

On Fri, 11 Nov 2016 08:50:56 -0700 Alex Williamson wrote: > On Fri, 11 Nov 2016 12:19:44 +0100 > Joerg Roedel wrote: > > > On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote: > > > In the case of x86, we know that DMA mappings

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/11/2016 06:19 AM, Joerg Roedel wrote: On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote: In the case of x86, we know that DMA mappings overlapping the MSI doorbells won't be translated correctly, it's not a valid mapping for that range, and therefore the iommu driver backing

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 11/11/2016 12:42, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 07:00:52PM +0100, Auger Eric wrote: >> GICv2m and GICV3 ITS use dma-mapping iommu_dma_map_msi_msg to allocate >> an MSI IOVA on-demand. > > Yes, and it the right thing to do there because as a DMA-API > implementation

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote: > +struct iommu_fwentry { > + struct list_head list; > + struct fwnode_handle *fwnode; > + const struct iommu_ops *ops; > +}; Is there a reason the iommu_ops need to be stored there? Currently it seems that the ops are

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

Hi Laurent, On 11/11/16 01:50, Laurent Pinchart wrote: > Hi Robin, > > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: >> On 20/10/16 00:36, Magnus Damm wrote: >>> From: Magnus Damm >>> >>> Introduce an alternative set of iommu_ops suitable for 64-bit ARM >>> as

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On 10/11/16 16:16, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 04:07:08PM +, Robin Murphy wrote: >> On 10/11/16 15:46, Joerg Roedel wrote: >>> On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: + resource_list_for_each_entry(window, >windows) { + if

Re: [RFC PATCH v3 03/20] x86: Add the Secure Memory Encryption cpu feature

On Wed, Nov 09, 2016 at 06:34:59PM -0600, Tom Lendacky wrote: > Update the cpu features to include identifying and reporting on the Here and for all other commit messages: s/cpu/CPU/g > Secure Memory Encryption feature. > ... -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On Thu, Nov 10, 2016 at 07:00:52PM +0100, Auger Eric wrote: > GICv2m and GICV3 ITS use dma-mapping iommu_dma_map_msi_msg to allocate > an MSI IOVA on-demand. Yes, and it the right thing to do there because as a DMA-API implementation the dma-iommu code cares about the address space allocation.

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

On Fri, Nov 11, 2016 at 03:13:32AM +0200, Laurent Pinchart wrote: > Joerg, as I've sent a few comments about the other patches (sorry for the > late > review, I got delayed by KS and LPC), the follow-up patch should probably be > squashed into this one when Magnus addresses my comments. Could