Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote:
>
> Remove all IOVA handling code from the non-dm
Any news on this? Is there anyone who wants to try and fix this possible bug?
On Mon, 23 Dec 2019 at 03:41, Jani Nikula wrote:
>
> On Mon, 23 Dec 2019, Robin Murphy wrote:
> > On 2019-12-23 10:37 am, Jani Nikula wrote:
> >> On Sat, 21 Dec 2019, Tom Murphy wrote:
> >>> This patchset converts the
IOTLB flush already included in the PASID tear down process. There
is no need to flush again.
Cc: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index
IOASID code is needed by VT-d scalable mode for PASID allocation.
Add explicit dependency such that IOASID is built-in whenever Intel
IOMMU is enabled.
Otherwise, aux domain code will fail when IOMMU is built-in and IOASID
is compiled as a module.
Signed-off-by: Jacob Pan
---
drivers/iommu/Kconf
Move canonical address check before mmget_not_zero() to avoid mm
reference leak.
Fixes: 9d8c3af31607 ("iommu/vt-d: IOMMU Page Request needs to check if
address is canonical.")
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
di
Just a few bug fixes while testing Intel SVM code.
Jacob Pan (3):
iommu/vt-d: Remove redundant IOTLB flush
iommu/vt-d: Fix mm reference leak
iommu/vt-d: Add build dependency on IOASID
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-svm.c | 13 ++---
2 files changed, 7 inserti
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
>> TBH, I don't see how
>>
>> if (force_dma_decrypted(dev))
>> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>>
>> makes more sense than the above. It's both non-sensical
On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
> Borislav Petkov writes:
>
> > On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
> >> Let me add another vote from a native English speaker that "unencrypted" is
> >> the appropriate term to imply the *absence* of encry
On Wed, 18 Mar 2020 17:14:05 +0100
Auger Eric wrote:
> Hi,
>
> On 3/18/20 1:00 PM, Robin Murphy wrote:
> > On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
> >> We don't currently support IOMMUs with a page granule larger than the
> >> system page size. The IOVA allocator has a BUG_ON() in
On Thu, Mar 19, 2020 at 12:54:59PM +, John Garry wrote:
> Hi Will,
>
> >
> > On Thu, Jan 02, 2020 at 05:44:39PM +, John Garry wrote:
> > > And for the overall system, we have:
> > >
> > >PerfTop: 85864 irqs/sec kernel:89.6% exact: 0.0% lost: 0/34434
> > > drop:
> > > 0/40116 [4
On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
> TBH, I don't see how
>
> if (force_dma_decrypted(dev))
> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>
> makes more sense than the above. It's both non-sensical unless there is
9087c37584fb
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
>> Let me add another vote from a native English speaker that "unencrypted" is
>> the appropriate term to imply the *absence* of encryption, whereas
>> "decrypted" implies the *reversal* of applied encryption.
Hello Robin,
On Thu, Mar 19, 2020 at 01:50:56PM +, Robin Murphy wrote:
> On 2020-03-02 6:16 pm, Alexander Dahl wrote:
> > ---
> > arch/x86/include/asm/dma.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.
On Wed, Mar 18, 2020 at 4:19 PM Will Deacon wrote:
>
> Hi Rob,
>
> On Mon, Feb 24, 2020 at 04:31:29PM -0600, Rob Herring wrote:
> > Arm SMMUv3.2 adds support for TLB range invalidate operations.
> > Support for range invalidate is determined by the RIL bit in the IDR3
> > register.
> >
> > The ran
On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> On Wed, Mar 18, 2020 at 3:48 PM Will Deacon wrote:
> >
> > On Tue, Jan 28, 2020 at 03:16:06PM -0700, Jordan Crouse wrote:
> > > Support auxiliary domains for arm-smmu-v2 to initialize and support
> > > multiple pagetables for a single SM
On Wed, Mar 18, 2020 at 01:27:53PM +0800, Lu Baolu wrote:
> On 2020/3/17 23:03, Qian Cai wrote:
> > dmar_find_atsr() calls list_for_each_entry_rcu() outside of an RCU read
> > side critical section but with dmar_global_lock held. Silence this
> > false positive.
> >
> > drivers/iommu/intel-iommu
On Tue, Mar 17, 2020 at 09:10:18AM +0800, Lu Baolu wrote:
> From: Jacob Pan
>
> Intel VT-d might support PRS (Page Reqest Support) when it's
> running in the scalable mode. Each page request descriptor
> occupies 32 bytes and is 32-bytes aligned. The page request
> descriptor offset mask should b
Hi Baolu,
On Sat, Mar 14, 2020 at 09:07:01AM +0800, Lu Baolu wrote:
> +static int iommu_group_change_def_domain(struct iommu_group *group, int type)
> +{
> + struct group_device *grp_dev, *temp;
> + struct iommu_domain *new, *old;
> + const struct iommu_ops *ops;
> + int ret = 0;
>
On 2020-03-02 6:16 pm, Alexander Dahl wrote:
For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4
("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's
a dependency on CONFIG_SWIOTLB, which was not necessarily active before.
The init code for swiotlb in 'pci
Hi Jean-Philippe,
On Mon, Mar 16, 2020 at 04:52:23PM +0100, Jean-Philippe Brucker wrote:
> Should be:
>
> if (!dev_iommu_priv_set(dev))
Thanks a lot for your reviews! I made the changes to arm-smmu and the
qcom driver you requested and will post a new version later today.
Thanks,
Hi Will,
On Thu, Jan 02, 2020 at 05:44:39PM +, John Garry wrote:
And for the overall system, we have:
PerfTop: 85864 irqs/sec kernel:89.6% exact: 0.0% lost: 0/34434 drop:
0/40116 [4000Hz cycles], (all, 96 CPUs)
-
On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
> Let me add another vote from a native English speaker that "unencrypted" is
> the appropriate term to imply the *absence* of encryption, whereas
> "decrypted" implies the *reversal* of applied encryption.
>
> Naming things is famously
[since this is in my inbox...]
On 2020-03-19 10:28 am, Borislav Petkov wrote:
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
So NAK - if you wa
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
> I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
> So NAK - if you want to change things it needs to go the other way.
We are already using "decrypt
On Thu, Mar 19, 2020 at 11:16:57AM +0100, Borislav Petkov wrote:
> Hi,
>
> here's v2 with build breakage fixed on ppc and s390 (obviously I can't
> grep :-\) and commit message extended to explain more why.
I thought we agreed that decrypted is absolutely the wrong term.
So NAK - if you want to
Hi,
here's v2 with build breakage fixed on ppc and s390 (obviously I can't
grep :-\) and commit message extended to explain more why.
Thx.
---
From: Borislav Petkov
Date: Tue, 17 Mar 2020 12:03:05 +0100
Back then when the whole SME machinery started getting mainlined, it
was agreed that for si
26 matches
Mail list logo
