On Mon Dec 16 19, Jerry Snitselaar wrote:
HP is seeing a panic on gen9 dl360 and dl560 while testing these other
changes we've been eorking on. I just took an initial look, but have
to run to a dentist appointment so couldn't dig too deep. It looks
like the device sets dev->archdata.iommu to DEFE
Hi,
On 2019/12/17 10:36, Liu, Yi L wrote:
From: Liu, Yi L
Sent: Tuesday, December 17, 2019 10:26 AM
To: Lu Baolu ; Joerg Roedel ; David
Woodhouse ; Alex Williamson
Subject: RE: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
first
level
From: Lu Baolu [mailto:baolu...@linux
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, December 17, 2019 9:39 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
> Hi,
>
> On 12/17/19 9:37 AM, L
> From: Liu, Yi L
> Sent: Tuesday, December 17, 2019 10:26 AM
> To: Lu Baolu ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: RE: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
> > From: Lu Baolu [mailto:baolu...@linux.intel.com]
> > Sent: Tu
> From: Lu Baolu < baolu...@linux.intel.com >
> Sent: Tuesday, December 17, 2019 10:04 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 4/6] iommu/vt-d: Setup pasid entries for iova over
> first level
>
> Hi Yi,
>
> On 12/15/19 5:37 PM, Liu, Yi
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, December 17, 2019 9:37 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
> Hi again,
>
> On 12/17/19 9:19
Hi Yi,
On 12/15/19 5:37 PM, Liu, Yi L wrote:
XD (bit 63) is only for the first level, and SNP (bit 11) is only for second
level, right? I
think we need to always set XD bit for IOVA over FL case. thoughts?
Oops, I made a mistake here. Please forget SNP bit, there is no way to control
SNP
with
Hi,
On 12/17/19 9:37 AM, Lu Baolu wrote:
You are right. I will change it accordingly. The logic should look
like:
if (domain attached to physical device)
flush_piotlb_with_RID2PASID()
else if (domain_attached_to_mdev_device)
flush_piotlb_with_default_pasid()
Both! so no "else" here
Hi again,
On 12/17/19 9:19 AM, Lu Baolu wrote:
Hi Yi,
On 12/15/19 5:22 PM, Liu, Yi L wrote:
Ok, let me explain more... default pasid is meaningful only when
the domain has been attached to a device as an aux-domain. right?
No exactly. Each domain has a specific default pasid, no matter norma
Hi Yi,
On 12/15/19 5:22 PM, Liu, Yi L wrote:
Ok, let me explain more... default pasid is meaningful only when
the domain has been attached to a device as an aux-domain. right?
No exactly. Each domain has a specific default pasid, no matter normal
domain (RID based) or aux-domain (PASID based).
HP is seeing a panic on gen9 dl360 and dl560 while testing these other
changes we've been eorking on. I just took an initial look, but have
to run to a dentist appointment so couldn't dig too deep. It looks
like the device sets dev->archdata.iommu to DEFER_DEVICE_DOMAIN_INFO
in intel_iommu_add_dev
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 regions of
memory that the firmware did not tell the
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 will be harvested from device's
default domain (
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 virtualization,
where FL performs guest virtual to guest
When Shared Virtual Address (SVA) is enabled for a guest OS via
vIOMMU, we need to provide invalidation support at IOMMU API and driver
level. This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for supporting caching
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to enable SVA virtualization, i.e. enable use of SVA
within a gues
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 changed, 5 insertions(+)
diff --git a/drivers/i
From: Lu Baolu
Enabling IOMMU in a guest requires communication with the host
driver for certain aspects. Use of PASID ID to enable Shared Virtual
Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
provides a Virtual Command Register (VCMD) to facilitate this.
Writes to this re
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel-iommu.h | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/in
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 always
come from the host. This ensures that PASI
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jacob Pan
---
drivers/iommu/dmar.c| 46
IOASIDs are system resources that can be shared by multiple drivers or
subsystems. When status of an IOASID changes at runtime, there is need
to notify all current users such that proper actions can be taken.
For example, an IOASID can be used by IOMMU subsystem for guest SVM as
well as KVM. When
IOASID/PASID are shared system resources that can be freed by software
components outside IOMMU subsystem. When status of an IOASID changes,
e.g. freed or suspended, notifications will be available to its users to
take proper action.
This patch adds a notification block such that when IOASID is fr
On 12/13/2019 5:52 PM, Lu Baolu wrote:
On 12/13/19 10:31 PM, Barret Rhoden wrote:
On 12/11/19 9:43 PM, Lu Baolu wrote:
The VT-d spec defines the BIOS considerations about RMRR in section
8.4:
"
BIOS must report the RMRR reported memory addresses as reserved (or as
EFI runtime) in the syste
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 regions of
memory that the firmware did not tell the kernel are reserved or
otherwise should
On Mon, Dec 16, 2019 at 8:38 AM Jordan Crouse wrote:
>
> Attempt to enable split pagetables if the arm-smmu driver supports it.
> This will move the default address space from the default region to
> the address range assigned to TTBR1. The behavior should be transparent
> to the driver for now bu
On Mon, Dec 16, 2019 at 6:36 AM Auger Eric wrote:
>On 12/16/19 3:24 PM, Qian Cai wrote:
> >
> > Looks like Joerg is away for a few weeks. Could Andrew or Linus pick up this
> > use-after-free?
I've taken it.
> Note the right version to pick up is the v4, reviewed by Jerry:
> https://www.mail-arc
Attempt to enable split pagetables if the arm-smmu driver supports it.
This will move the default address space from the default region to
the address range assigned to TTBR1. The behavior should be transparent
to the driver for now but it gets the default buffers out of the way
when we want to sta
Refactor how address space initialization works. Instead of having the
address space function create the MMU object (and thus require separate but
equal functions for gpummu and iommu) use a single function and pass the
MMU struct. Make the generic code cleaner by using target specific
functions to
Add support to enable split pagetables (TTBR1) if the supporting driver
requests it via the DOMAIN_ATTR_SPLIT_TABLES flag. When enabled, the driver
will set up the TTBR0 and TTBR1 regions and program the default domain
pagetable on TTBR1.
After attaching the device, the value of he domain attribut
Add a new attribute to enable and query the state of split pagetables
for the domain.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f2223cb..18c861e 100644
--- a/include/linux/iommu.
address space for the TTBR1 range.
These patches are on based on top of linux-next-20191216 with [1], [2], and [3]
from Robin on the iommu list.
Change log:
v3: Remove the implementation specific and make split pagetable support
part of the generic configuration
[1] https://lists.linuxfoundation.org
Everywhere an IOMMU object is created by msm_gpu_create_address_space
the IOMMU device is attached immediately after. Instead of carrying around
the infrastructure to do the attach from the device specific code do it
directly in the msm_iommu_init() function. This gets it out of the way for
more ag
Hi,
On 12/16/19 3:24 PM, Qian Cai wrote:
>
>
>> On Nov 26, 2019, at 5:27 AM, Eric Auger wrote:
>>
>> In case the new region gets merged into another one, the nr
>> list node is freed. Checking its type while completing the
>> merge algorithm leads to a use-after-free. Use new->type
>> instead.
>
> On Nov 26, 2019, at 5:27 AM, Eric Auger wrote:
>
> In case the new region gets merged into another one, the nr
> list node is freed. Checking its type while completing the
> merge algorithm leads to a use-after-free. Use new->type
> instead.
>
> Fixes: 4dbd258ff63e ("iommu: Revisit iommu_in
On Mon, 2019-11-04 at 19:52 +0800, Chao Hao wrote:
> 1. Add mt6779 registers define for iommu.
> 2. Add mt6779_data define to support mt6779 iommu HW init.
> 3. There are two iommus, one is mm_iommu, the other is vpu_iommu.
> MM_IOMMU is connected smi_larb to support multimedia engine to
> access D
On Mon, 2019-11-04 at 19:52 +0800, Chao Hao wrote:
> Start with this patch, we will change the SW architecture
> to support multiple domains. SW architecture will has a big change,
> so we need to modify a little bit by more than one patch.
> The new SW overall architecture is as below:
>
>
On Mon, 2019-11-04 at 19:52 +0800, Chao Hao wrote:
> This patch adds description for MT6779 IOMMU.
>
> MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
> use ARM Short-Descriptor translation format.
>
> The MT6779 IOMMU hardware diagram is as below, it is only a brief
> diagram about
38 matches
Mail list logo
