hi baolu,
We run this on zhaoxin X86 paltform.
There are some MCUS on our platforms that read and write data to
the system memory.
During this process, the MCU is invisible to the host kernel. And the MCU needs
to report through ACPI_NAMESPACE_DEVICE in RMRR.
Hi Kevin,
On 9/4/20 10:16 AM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Friday, September 4, 2020 9:03 AM
If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
table, we could default to the device NUMA domain as fall back. This could
also benefit a vIOMMU use case where only
> From: Lu Baolu
> Sent: Friday, September 4, 2020 9:03 AM
>
> If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
> table, we could default to the device NUMA domain as fall back. This could
> also benefit a vIOMMU use case where only single vIOMMU is exposed,
> hence
> no
If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
table, we could default to the device NUMA domain as fall back. This could
also benefit a vIOMMU use case where only single vIOMMU is exposed, hence
no RHSA will be present but device numa domain can be correct.
Cc: Jacob Pan
Hi, Thomas, Andy, et al,
On Thu, Aug 27, 2020 at 08:06:34AM -0700, Fenghua Yu wrote:
> A PASID is allocated for an "mm" the first time any thread binds
> to an SVM capable device and is freed from the "mm" when the SVM is
> unbound by the last thread. It's possible for the "mm" to have different
On Tue, 1 Sep 2020 13:51:26 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 8/22/20 6:35 AM, Jacob Pan wrote:
> > ioasid_set was introduced as an arbitrary token that are shared by
> > a
> that is
got it
> > group of IOASIDs. For example, if IOASID #1 and #2 are allocated
> > via the same
Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 94 ++---
drivers/iommu/intel/iommu.c | 6 +++
drivers/iommu/iommu.c | 10
to dma-iommu ops
Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 9 +
include/linux/dma-iommu.h | 3 +++
2 files changed, 12 insertions(+)
diff --git
On Fri, 28 Aug 2020 at 00:34, Tom Murphy wrote:
>
> On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe wrote:
> >
> >
> >
> > On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> > > I have added a check for the sg_dma_len == 0 :
> > > """
> > > } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > >
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
Allow the iommu_unmap_fast to return newly freed page table pages and
pass the freelist to queue_iova in the dma-iommu ops path.
This is useful for iommu drivers (in this case the intel iommu driver)
which need to wait for the ioTLB to be flushed before newly
free/unmapped page table pages can be
Disable combining sg segments in the dma-iommu api.
Combining the sg segments exposes a bug in the intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value
Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.
Signed-off-by: Tom Murphy
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel/iommu.c | 756 +++-
2 files changed, 51
Ashok,
On Thu, Sep 03 2020 at 09:35, Ashok Raj wrote:
> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
>> This is the second version of providing a base to support device MSI (non
>> PCI based) and on top of that support for IMS (Interrupt Message Storm)
>
> s/Storm/Store
>
>
On Wed, Sep 2, 2020 at 8:52 PM Nathan Chancellor
wrote:
>
> On Wed, Sep 02, 2020 at 05:36:29PM -0700, Florian Fainelli wrote:
> >
> >
> > On 9/2/2020 3:38 PM, Nathan Chancellor wrote:
> > [snip]
> > > > Hello Nathan,
> > > >
> > > > Can you tell me how much memory your RPI has and if all of it is
On Thu, Sep 03, 2020 at 12:34:04PM +0100, Robin Murphy wrote:
> The attempt to handle huge page allocations was originally added since
> the comments around stripping __GFP_COMP in other implementations were
> nonsensical, and we naively assumed that split_huge_page() could simply
> be called
Hi Thomas,
Thanks a ton for jumping in helping on straightening it for IMS!!!
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> This is the second version of providing a base to support device MSI (non
> PCI based) and on top of that support for IMS (Interrupt Message Storm)
FYI, I've moved it off for-next and into its own dma-ranges branch
for now until we sort out the regressions. I still hope to bring it
back soon.
___
iommu mailing list
iommu@lists.linux-foundation.org
The attempt to handle huge page allocations was originally added since
the comments around stripping __GFP_COMP in other implementations were
nonsensical, and we naively assumed that split_huge_page() could simply
be called equivalently to split_page(). It turns out that this doesn't
actually work
On Tue, Aug 25, 2020 at 4:19 PM Lad Prabhakar
wrote:
> Add the five IPMMU instances found in the r8a7742 to DT with a disabled
> status.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Chris Paterson
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.10.
On Tue, Aug 25, 2020 at 4:19 PM Lad Prabhakar
wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> No driver change is needed due to the fallback compatible value
> "renesas,ipmmu-vmsa".
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Chris Paterson
Reviewed-by: Geert Uytterhoeven
Currently, the RemapEn (valid) bit is accidentally cleared when
programming IRTE w/ guestMode=0. It should be restored to
the prior state.
Reviewed-by: Joao Martins
Signed-off-by: Suravee Suthikulpanit
Fixes: b9fc6b56f478 ("iommu/amd: Implements irq_set_vcpu_affinity() hook to
setup vapic mode
Interrupt remapping IO_PAGE_FAULT has been observed under system w/
large number of VMs w/ pass-through devices. This can be reproduced with
64 VMs + 64 pass-through VFs of Mellanox MT28800 Family [ConnectX-5 Ex],
where each VM runs small-packet netperf test via the pass-through device
to the
When using 128-bit interrupt-remapping table entry (IRTE) (a.k.a GA mode),
current driver disables interrupt remapping when it updates the IRTE
so that the upper and lower 64-bit values can be updated safely.
However, this creates a small window, where the interrupt could
arrive and result in
Hi Jacob,
On 8/31/20 8:24 PM, Jacob Pan wrote:
> IOMMU user APIs are responsible for processing user data. This patch
> changes the interface such that user pointers can be passed into IOMMU
> code directly. Separate kernel APIs without user pointers are introduced
> for in-kernel users of the
Hi Jacob,
On 8/31/20 8:25 PM, Jacob Pan wrote:
> IOMMU generic layer already does sanity checks on UAPI data for version
> match and argsz range based on generic information.
>
> This patch adjusts the following data checking responsibilities:
> - removes the redundant version check from VT-d
Hi,
I'll send out V2 with fixes to the review comments below ...
On 9/2/20 10:26 PM, Joao Martins wrote:
On 9/2/20 5:51 AM, Suravee Suthikulpanit wrote:
When using 128-bit interrupt-remapping table entry (IRTE) (a.k.a GA mode),
current driver disables interrupt remapping when it updates the
On Thu, Sep 03, 2020 at 10:43:02AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2020 at 07:38:10PM +0200, Thomas Bogendoerfer wrote:
> > this is the problem:
> >
> >/* Always check for received packets. */
> > sgiseeq_rx(dev, sp, hregs, sregs);
> >
> > so the driver will
On Wed, Sep 02, 2020 at 11:38:09PM +0200, Thomas Bogendoerfer wrote:
> the patch below fixes the problem.
But is very wrong unfortunately.
> static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct
On Tue, Sep 01, 2020 at 07:38:10PM +0200, Thomas Bogendoerfer wrote:
> this is the problem:
>
>/* Always check for received packets. */
> sgiseeq_rx(dev, sp, hregs, sregs);
>
> so the driver will look at the rx descriptor on every interrupt, so
> we cache the rx descriptor on the
On 03.09.20 08:51, Lu Baolu wrote:
> The dev_iommu_priv_set() must be called after probe_device(). This fixes
> a NULL pointer deference bug when booting a system with kernel cmdline
> "intel_iommu=on,igfx_off", where the dev_iommu_priv_set() is abused.
[...]
>
> Fixes: 01b9d4e21148c
Hi Felix,
On 9/2/20 11:24 AM, FelixCui-oc wrote:
hi baolu,
So you have a hidden device (invisible to host kernel). But you need to
setup some identity mappings for this device, so that the firmware
could keep working, right?
The platform designs this by putting that range in the RMRR
The dev_iommu_priv_set() must be called after probe_device(). This fixes
a NULL pointer deference bug when booting a system with kernel cmdline
"intel_iommu=on,igfx_off", where the dev_iommu_priv_set() is abused.
The following stacktrace was produced:
[0.00] Command line:
Hi Robin,
On 9/2/20 7:31 PM, Robin Murphy wrote:
On 2020-09-02 06:32, Torsten Hilbrich wrote:
After updating from v5.8 to v5.9-rc2 I noticed some problems when
booting a system with kernel cmdline "intel_iommu=on,igfx_off".
The following stacktrace was produced:
<6>[ 0.00] Command
34 matches
Mail list logo
