On Thu, Nov 14, 2019 at 02:14:47PM +0800, Adrian Huang wrote:
> Some buggy BIOSes might define multiple exclusion ranges of the
> IVMD entries which are associated with the same IOMMU hardware.
> This leads to the overwritten exclusion range (exclusion_start
> and exclusion_length members) in
On Mon, Dec 09, 2019 at 07:47:25PM +, Robin Murphy wrote:
> Since commit ece6e6f0218b ("iommu/dma-iommu: Split iommu_dma_map_msi_msg()
> in two parts"), iommu_dma_prepare_msi() should no longer have to worry
> about preempting itself, nor being called in atomic context at all. Thus
> we can
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Named component nodes in the IORT tables describe the number of
> Substream ID bits (aka. PASID) supported by the device. Propagate this
> value to the fwspec structure in order to enable PASID for platform
> devices.
>
> Acked-by:
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> When adding SSID support to the SMMUv3 driver, we'll need to manipulate
> leaf pasid tables and context descriptors. Extract the context
> descriptor structure and introduce a new table structure.
>
> Signed-off-by: Jean-Philippe
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits, which will also be used for PCI
> PASID.
>
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Since commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> dma_alloc_*"), dma_alloc_* always initializes memory to zero, so there
> is no need to use dma_zalloc_* or pass the __GFP_ZERO flag anymore.
>
> The flag was
On Mon, Dec 09, 2019 at 03:50:04PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Use the new standard function instead of open-coding it.
>
> Cc: Will Deacon
> Cc: Robin Murphy
> Signed-off-by: Thierry Reding
> ---
> drivers/iommu/arm-smmu-v3.c | 11 +--
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Support for SSID will require allocating context descriptor tables. Move
> the context descriptor allocation to separate functions.
>
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Thanks
Eric
> ---
>
On Thu, Nov 28, 2019 at 04:48:52PM -0800, Cong Wang wrote:
> This patchset contains three small optimizations for the global spinlock
> contention in IOVA cache. Our memcache perf test shows this reduced its
> p999 latency down by 45% on AMD when IOMMU is enabled.
Sounds nice. Can you please
On Tue, Dec 10, 2019 at 12:27:04PM +0800, Xiaotao Yin wrote:
> Fixes: bb68b2fbfbd6 ("iommu/iova: Add rbtree anchor node")
> Signed-off-by: Xiaotao Yin
> Reviewed-by: Robin Murphy
> ---
> drivers/iommu/iova.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Okay, missed that. Replaced
Hi Alex,
On Thu, Dec 12, 2019 at 12:27:11PM -0700, Alex Williamson wrote:
> Sure, if you remember the ordering between these then that might be the
> better option. I checked that they both entered the kernel for
> v5.3-rc1 but didn't dig deeper than that.
>
> Joerg, if you'd like a respin for
On Wed, Dec 11, 2019 at 08:02:35PM +0100, Christoph Hellwig wrote:
> On Wed, Dec 11, 2019 at 06:33:26PM +, Robin Murphy wrote:
> > Since iommu_dma_alloc_iova() combines incoming masks with the u64 bus
> > limit, it makes more sense to pass them around in their native u64
> > rather than
On Wed, Dec 11, 2019 at 08:54:21AM +0800, Lu Baolu wrote:
> On 12/11/19 2:56 AM, Jerry Snitselaar wrote:
> > iommu_group_create_direct_mappings uses group->default_domain, but
> > right after it is called, request_default_domain_for_dev calls
> > iommu_domain_free for the default domain, and sets
On Wed, Nov 20, 2019 at 07:55:47AM -0600, Suravee Suthikulpanit wrote:
> Adding feature support check for MMIO access to MSI capability
> block registers when enabling x2APIC (XT) mode. Also fix up logic
> for checking XT feature support for IVHD type 10h.
>
> Suravee Suthikulpanit (2):
>
On Thu, Nov 21, 2019 at 04:19:30AM +0100, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1.
On Sun, Dec 15, 2019 at 01:39:31PM +0800, Lu Baolu wrote:
> Hi,
>
> On 12/13/19 1:36 PM, Jerry Snitselaar wrote:
> > Currently the reserved region for ISA is allocated with no
> > permissions. If a dma domain is being used, mapping this region will
> > fail. Set the permissions to
On Fri, Dec 06, 2019 at 01:57:41PM +0800, Kai-Heng Feng wrote:
> Hi Joerg,
>
> > On Dec 3, 2019, at 01:00, Christoph Hellwig wrote:
> >
> > On Fri, Nov 29, 2019 at 10:21:54PM +0800, Kai-Heng Feng wrote:
> >> Serious screen flickering when Stoney Ridge outputs to a 4K monitor.
> >>
> >>
On Mon, Dec 09, 2019 at 04:24:04PM +0800, Xiaotao Yin wrote:
> The reason:
> When alloc_iova_mem() without initial with Zero, sometimes fpn_lo will equal
> to
> IOVA_ANCHOR by chance, so when return from __alloc_and_insert_iova_range()
> with
> -ENOMEM(iova32_full), the new_iova will not be
Hi Thierry
On Mon, Dec 09, 2019 at 03:50:02PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Most IOMMU drivers only need to free the memory allocated for each
> reserved region. Instead of open-coding the loop to do this in each
> driver, extract the code into a common function that
Hi Bjorn,
On Tue, Dec 10, 2019 at 04:37:45PM -0600, Bjorn Helgaas wrote:
> Heads up Joerg: I also updated drivers/iommu/amd_iommu.c (this is the
> one reported by the kbuild test robot) and removed the printk there
> that prints the same thing as the one in pci_add_dma_alias(), and I
> updated a
On Wed, Dec 11, 2019 at 09:40:15AM +0800, Lu Baolu wrote:
> If the default DMA domain of a group doesn't fit a device, it
> will still sit in the group but use a private identity domain.
> When map/unmap/iova_to_phys come through iommu API, the driver
> should still serve them, otherwise, other
Hi Eric,
On Tue, Dec 17, 2019 at 12:05:18PM +0100, Auger Eric wrote:
> > + fwspec = dev_iommu_fwspec_get(dev);
> > + if (!err && fwspec)
> > + of_property_read_u32(master_np, "pasid-num-bits",
> > +>num_pasid_bits);
> >
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
> addition to
Hi Jean,
On 12/17/19 4:21 PM, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On Tue, Dec 17, 2019 at 12:05:18PM +0100, Auger Eric wrote:
>>> + fwspec = dev_iommu_fwspec_get(dev);
>>> + if (!err && fwspec)
>>> + of_property_read_u32(master_np, "pasid-num-bits",
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Second-level context descriptor tables will be allocated lazily in
> arm_smmu_write_ctx_desc(). Help with handling allocation failure by
> moving the CD write into arm_smmu_domain_finalise_s1().
nit: would rather change the title to
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
s/Propate/Propagate in the commit title.
> Now that we support substream IDs, initialize s1cdmax with the number of
> SSID bits supported by a master and the SMMU.
>
> Context descriptor tables are allocated once for the first master
>
In addition to checking for a null pointer, verify that
info does not have the value DEFER_DEVICE_DOMAIN_INFO or
DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values
__dmar_remove_one_dev_info will panic when trying to access
a member of the device_domain_info struct.
[1.464241] BUG:
On Tue, Dec 17, 2019 at 10:56 AM Jerry Snitselaar wrote:
>
> In addition to checking for a null pointer, verify that
> info does not have the value DEFER_DEVICE_DOMAIN_INFO or
> DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values
> __dmar_remove_one_dev_info will panic when trying to access
On 12/16/2019 11:35 AM, Barret Rhoden wrote:
On 12/16/19 2:07 PM, Chen, Yian wrote:
On 12/11/2019 11:46 AM, Barret Rhoden wrote:
RMRR entries describe memory regions that are DMA targets for devices
outside the kernel's control.
RMRR entries that fail the sanity check are pointing to
On Tue Dec 17 19, Jerry Snitselaar wrote:
On Tue Dec 17 19, Jerry Snitselaar wrote:
In addition to checking for a null pointer, verify that
info does not have the value DEFER_DEVICE_DOMAIN_INFO or
DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values
__dmar_remove_one_dev_info will panic
On Tue Dec 17 19, Jerry Snitselaar wrote:
In addition to checking for a null pointer, verify that
info does not have the value DEFER_DEVICE_DOMAIN_INFO or
DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values
__dmar_remove_one_dev_info will panic when trying to access
a member of the
Both find_iova() and __free_iova() take iova_rbtree_lock,
there is no reason to take and release it twice inside
free_iova().
Fold them into one critical section by calling the unlock
versions instead.
Cc: Joerg Roedel
Cc: John Garry
Signed-off-by: Cong Wang
---
drivers/iommu/iova.c | 8
This patchset contains three small optimizations for the global spinlock
contention in IOVA cache. Our memcache perf test shows this reduced its
p999 latency down by 45% on AMD when IOMMU is enabled.
(Resending v3 on Joerg's request.)
Cong Wang (3):
iommu: avoid unnecessary magazine
If the magazine is empty, iova_magazine_free_pfns() should
be a nop, however it misses the case of mag->size==0. So we
should just call iova_magazine_empty().
This should reduce the contention on iovad->iova_rbtree_lock
a little bit, not much at all.
Cc: Joerg Roedel
Cc: John Garry
The IOVA cache algorithm implemented in IOMMU code does not
exactly match the original algorithm described in the paper
"Magazines and Vmem: Extending the Slab Allocator to Many
CPUs and Arbitrary Resources".
Particularly, it doesn't need to free the loaded empty magazine
when trying to put it
Hi,
On 12/17/19 3:24 AM, Jacob Pan wrote:
Virtual command registers are used in the guest only, to prevent
vmexit cost, we cache the capability and store it during initialization.
Signed-off-by: Jacob Pan
---
drivers/iommu/dmar.c| 1 +
include/linux/intel-iommu.h | 4
2 files
Hi,
On 12/17/19 3:24 AM, Jacob Pan wrote:
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page tables, it
On Wed, 2019-12-04 at 12:35:24 UTC, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a
> system has more physical memory than this limit, the swiotlb buffer is not
> addressable because it is allocated from memblock using
Hi again,
On 12/17/19 3:24 AM, Jacob Pan wrote:
+/**
+ * intel_pasid_setup_nested() - Set up PASID entry for nested translation
+ * which is used for vSVA. The first level page tables are used for
+ * GVA-GPA or GIOVA-GPA translation in the guest, second level page tables
+ * are used for
Hi,
On 12/17/19 3:24 AM, Jacob Pan wrote:
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch registers a
custom IOASID allocator which takes precedence over the default
XArray based allocator. The resulting IOASID allocation will
Hi Jacob,
On 12/17/19 3:24 AM, Jacob Pan wrote:
Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA
41 matches
Mail list logo
