The VT-d spec Revision 3.3 updated the virtual command registers, virtual
command opcode B register, virtual command response register and virtual
command capability register (Section 10.4.43, 10.4.44, 10.4.45, 10.4.46).
This updates the virtual command interface implementation in the Intel
IOMMU d
On 7/12/21 11:47 PM, Ville Syrjälä wrote:
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
On 7/10/21 12:47 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a DMAR
write
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> > > "Tian, Kevin" wrote:
>
> > > > For mdev the struct
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> > > "Tian, Kevin" wrote:
>
> > > > For mdev the struct
On Mon, 12 Jul 2021 01:22:11 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Saturday, July 10, 2021 5:51 AM
> > On Fri, 9 Jul 2021 07:48:44 +
> > "Tian, Kevin" wrote:
> > > For mdev the struct device should be the pointer to the parent device.
> >
> > I don't get how i
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
> On 7/10/21 12:47 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While running "gem_exec_big --r single" from igt-gpu-tools on
> > Geminilake as soon as a 2M mapping is made I tend to get a DMAR
> > write fault. Strangely the fa
On Tue, Jun 22, 2021 at 11:56 PM Krzysztof Kozlowski
wrote:
>
> On Mon, 21 Jun 2021 16:00:36 +0200, Thierry Reding wrote:
> > Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> > string") introduced a jsonschema syntax error as a result of a rebase
> > gone wrong. Fix it.
>
> A
On Tue, Jul 06, 2021 at 12:59:57PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> > On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > > On Tue, J
> > Should we be checking alignment here? Something like
> >
> > BUG_ON(paddr & ((1 << DART_TTBR_SHIFT) - 1));
> >
>
> Sure, right now paddr will always be aligned but adding that
> BUG_ON doesn't hurt :)
Probably should have suggested WARN_ON instead of BUG_ON but yes.
We only ever now set strict mode enabled in iommu_set_dma_strict(), so
just remove the argument.
Signed-off-by: John Garry
Reviewed-by: Robin Murphy
Reviewed-by: Lu Baolu
---
drivers/iommu/amd/init.c| 2 +-
drivers/iommu/intel/iommu.c | 6 +++---
drivers/iommu/iommu.c | 5 ++---
incl
From: Zhen Lei
Make IOMMU_DEFAULT_LAZY default for when AMD_IOMMU config is set, which
matches current behaviour.
For "fullflush" param, just call iommu_set_dma_strict(true) directly.
Since we get a strict vs lazy mode print already in iommu_subsys_init(),
and maintain a deprecation print when
From: Zhen Lei
Make IOMMU_DEFAULT_LAZY default for when INTEL_IOMMU config is set,
as is current behaviour.
Also delete global flag intel_iommu_strict:
- In intel_iommu_setup(), call iommu_set_dma_strict(true) directly. Also
remove the print, as iommu_subsys_init() prints the mode and we have
From: Zhen Lei
First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the two config options in an choice, as they are mutually exclusive.
[jpg: Make choice between strict and lazy only (and not passthrou
As well as the default domain type, it's useful to know whether strict
or lazy for DMA domains, so add this info in a separate print.
The (stict/lazy) mode may be also set via iommu.strict earlyparm, but
this will be processed prior to iommu_subsys_init(), so that print will be
accurate for driver
Now that the x86 drivers support iommu.strict, deprecate the custom
methods.
Signed-off-by: John Garry
Acked-by: Robin Murphy
Reviewed-by: Lu Baolu
---
Documentation/admin-guide/kernel-parameters.txt | 9 ++---
drivers/iommu/amd/init.c| 4 +++-
drivers/iommu/intel/i
This is a reboot of Zhen Lei's series from a couple of years ago, which
never made it across the line.
I still think that it has some value, so taking up the mantle.
Motivation:
Allow lazy mode be default mode for DMA domains for all ARCHs, and not
only those who hardcode it (to be lazy). For ARM
Hi,
On Wed, Jun 30, 2021, at 15:49, Alyssa Rosenzweig wrote:
> Looks really good! Just a few minor comments. With them addressed,
>
> Reviewed-by: Alyssa Rosenzweig
Thanks!
>
> > + Say Y here if you are using an Apple SoC with a DART IOMMU.
>
> Nit: Do we need to spell out "with a
Restore bits 39 to 32 at correct position.
It reverses the operation done in rk_dma_addr_dte_v2().
Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2")
Reported-by: Dan Carpenter
Signed-off-by: Benjamin Gaignard
---
version 3:
- change commit header to match with IOMMU tree conven
Hi Christoph and Robin:
I introduced new interface set_memory_decrypted_map() to hide all
the hypervisor code behind it in the latest version. In current generic
code, only swiotlb bounce buffer needs to be decrypted and remapped in
the same time and so keep set_memory_decrypted(). If there
From: Alexander Monakov
[ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ]
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The seco
From: Alexander Monakov
[ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ]
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The seco
The commit 2b0140c69637e ("iommu/vt-d: Use pci_real_dma_dev() for mapping")
fixes an issue of "sub-device is removed where the context entry is cleared
for all aliases". But this commit didn't consider the PASID entry and PASID
table in VT-d scalable mode. This fix increases the coverage of scalabl
From: Sanjay Kumar
This fixes a bug in context cache clear operation. The code was not
following the correct invalidation flow. A global device TLB invalidation
should be added after the IOTLB invalidation. At the same time, it
uses the domain ID from the context entry. But in scalable mode, the
23 matches
Mail list logo