When a present pasid entry is disassembled, all kinds of pasid related
caches need to be flushed. But when a pasid entry is not being used
(PRESENT bit not set), we don't need to do this. Check the PRESENT bit
in intel_pasid_tear_down_entry() and avoid flushing caches if it's not
set.
Signed-off-b
When first-level page tables are used for IOVA translation, we use user
privilege by setting U/S bit in the page table entry. This is to make it
consistent with the second level translation, where the U/S enforcement
is not available. Clear the SRE (Supervisor Request Enable) field in the
pasid tab
Hi Joerg,
This series includes some misc fixes for the VT-d iommu driver. Please
help to review and merge.
Best regards,
baolu
Lu Baolu (5):
iommu/vt-d: Report the right page fault address
iommu/vt-d: Remove WO permissions on second-level paging entries
iommu/vt-d: Invalidate PASID cache w
When the first level page table is used for IOVA translation, it only
supports Read-Only and Read-Write permissions. The Write-Only permission
is not supported as the PRESENT bit (implying Read permission) should
always set. When using second level, we still give separate permissions
that allows Wr
When the Intel IOMMU is operating in the scalable mode, some information
from the root and context table may be used to tag entries in the PASID
cache. Software should invalidate the PASID-cache when changing root or
context table entries.
Suggested-by: Ashok Raj
Fixes: 7373a8cc38197 ("iommu/vt-d
The Address field of the Page Request Descriptor only keeps bit [63:12]
of the offending address. Convert it to a full address before reporting
it to device drivers.
Fixes: eb8d93ea3c1d3 ("iommu/vt-d: Report page request faults for guest SVA")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.
On Tue, Feb 23, 2021 at 08:10:41AM +0300, Dmitry Osipenko wrote:
> 23.02.2021 05:13, Nicolin Chen пишет:
> > Hi Dmitry,
> >
> > On Sat, Feb 20, 2021 at 08:16:22AM +0300, Dmitry Osipenko wrote:
> >> 19.02.2021 01:07, Nicolin Chen пишет:
> >>> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smm
The lazy IOTLB flushing setup leaves a time window, in which the device
can still access some system memory, which has already been unmapped by
the device driver. It's not suitable for untrusted devices. A malicious
device might use this to attack the system by obtaining data that it
shouldn't obta
Hi Christoph and all,
On 23.02.21 10:56, Guillaume Tucker wrote:
Hi Christoph,
Please see the bisection report below about a boot failure on
r8a77960-ulcb on next-20210222.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
Dear Suravee,
Thank you for your reply.
Am 22.02.21 um 18:59 schrieb Suravee Suthikulpanit:
This fix has been accepted in the upstream recently.
https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/commit/?h=x86/amd
Indeed. Linux pulled also pulled this [1].
Could you please g
The pull request you sent on Wed, 24 Feb 2021 08:46:01 +0100:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a4dec04c7ff4307973ba502ce7b27330d9fe04b7
Thank you!
--
Deet-doot-dot, I am a bot.
h
Hi Fenghua,
[Trimmed the Cc list]
On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote:
> When a new mm is created, its PASID should be cleared, i.e. the PASID is
> initialized to its init state 0 on both ARM and X86.
I just noticed this patch was dropped in v7, and am wondering whether we
12 matches
Mail list logo
