On Tue, Aug 03, 2021 at 03:19:26AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Tuesday, August 3, 2021 9:51 AM
> >
> > On Wed, Jul 28, 2021 at 04:04:24AM +, Tian, Kevin wrote:
> > > Hi, David,
> > >
> > > > From: David Gibson
> > > > Sent: Monday, July 26, 2021 12:51 PM
> > >
On Wed, Aug 04, 2021 at 11:04:47AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
>
> > Can you elaborate? IMO the user only cares about the label (device cookie
> > plus optional vPASID) which is generated by itself when doing the attaching
> >
On Wed, Aug 04, 2021 at 11:07:42AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 11:58:54AM +1000, David Gibson wrote:
> > > I'd rather deduce the endpoint from a collection of devices than the
> > > other way around...
> >
> > Which I think is confusing, and in any case doesn't cover
On Thu, Aug 5, 2021 at 1:18 AM Robin Murphy wrote:
>
> The core code bakes its own cookies now.
>
> CC: Chunyan Zhang
> Signed-off-by: Robin Murphy
Thank you for the patch!
Acked-by: Chunyan Zhang
>
> ---
>
> v3: Also remove unneeded include
> ---
> drivers/iommu/sprd-iommu.c | 7 ---
>
> From: Jason Gunthorpe
> Sent: Thursday, August 5, 2021 7:27 PM
>
> On Wed, Aug 04, 2021 at 10:59:21PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, August 4, 2021 10:05 PM
> > >
> > > On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
> > >
> > > > Can
On 8/5/2021 7:03 PM, Lorenzo Pieralisi wrote:
> On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
>
> [...]
>
>> +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
>> +{
>> +struct acpi_iort_node *smmu;
>> +struct acpi_iort_rmr *rmr;
>> +
On 2021-08-05 16:16, John Garry wrote:
On 05/08/2021 15:41, Robin Murphy wrote:
I suppose they could be combined into a smaller sub-struct and loaded
in a single operation, but it looks messy, and prob without much gain.
Indeed I wouldn't say that saving memory is the primary concern here,
On Thu, Aug 5, 2021 at 6:03 PM Lorenzo Pieralisi
wrote:
>
> On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
>
> [...]
>
> > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> > +{
> > + struct acpi_iort_node *smmu;
> > + struct acpi_iort_rmr
Lennert,
FYI: I have made some comments in V2 thread specifically around the new changes
that we discussed in that thread.
Thanks,
Suravee
___
iommu mailing list
iommu@lists.linux-foundation.org
Lennert,
On 7/29/2021 9:32 PM, Lennert Buytenhek wrote:
We have three cases to handle:
- EVENT_FLAG_I set: IRQ remapping fault, don't call report_iommu_fault()
- EVENT_FLAG_I unset, but the request was a translation request
(EVENT_FLAG_TR set) or the target page was not present
On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
[...]
> +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> +{
> + struct acpi_iort_node *smmu;
> + struct acpi_iort_rmr *rmr;
> + struct acpi_iort_rmr_desc *rmr_desc;
> + u32 map_count =
Hi Konrad:
Could you have a look at this new version? The change since v1 is
make swiotlb_init_io_tlb_mem() return error code when
dma_map_decrypted() fails according your previous comment. If this
change is ok, could you give your ack and this series needs to be merged
via Hyper-V next
Hi Christoph:
Could you have a look at this patch? It adds new API
dma_map_decrypted() to do memory decrypted and remap. It will
be used in the swiotlb code.
Thanks.
On 8/5/2021 2:45 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Hyper-V Isolation VM with AMD SEV, swiotlb boucne buffer
On 8/5/2021 10:29 PM, Dave Hansen wrote:
On 8/5/21 7:23 AM, Peter Zijlstra wrote:
This is assuming any of this is actually performance critical, based off
of this using static_call() to begin with.
This code is not performance critical.
I think I sent folks off on a wild goose chase when I
On Thu, Aug 05, 2021 at 09:07:19AM +0100, Shameer Kolothum wrote:
> Add a helper function (iort_iommu_get_rmrs()) that retrieves RMR
> memory descriptors associated with a given IOMMU. This will be used
> by IOMMU drivers to setup necessary mappings.
>
> Invoke it from the generic helper
On 05/08/2021 15:41, Robin Murphy wrote:
I suppose they could be combined into a smaller sub-struct and loaded
in a single operation, but it looks messy, and prob without much gain.
Indeed I wouldn't say that saving memory is the primary concern here,
and any more convoluted code is hardly
On 2021-08-05 14:40, John Garry wrote:
On 05/08/2021 12:24, Robin Murphy wrote:
On 2021-06-21 17:36, John Garry wrote:
Members of struct "llq" will be zero-inited, apart from member
max_n_shift.
But we write llq.val straight after the init, so it was pointless to
zero
init those other
On 8/5/21 7:23 AM, Peter Zijlstra wrote:
> This is assuming any of this is actually performance critical, based off
> of this using static_call() to begin with.
This code is not performance critical.
I think I sent folks off on a wild goose chase when I asked that we make
an effort to optimize
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> {
> + return static_call(x86_set_memory_enc)(addr, numpages, enc);
> }
Hurpmh... So with a bit of 'luck' you get code-gen like:
__set_memory_enc_dec:
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool
> enc)
> +{
> + return 0;
> +}
> +
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
That's spelled:
On Thu, 5 Aug 2021 at 15:35, Shameerali Kolothum Thodi
wrote:
>
>
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:a...@kernel.org]
> > Sent: 05 August 2021 14:23
> > To: Shameerali Kolothum Thodi
> > Cc: Linux ARM ; ACPI Devel Maling List
> > ; Linux IOMMU
> > ; Linuxarm ;
> >
Hi Dave:
Thanks for review.
On 8/5/2021 3:27 AM, Dave Hansen wrote:
On 8/4/21 11:44 AM, Tianyu Lan wrote:
+static int default_set_memory_enc(unsigned long addr, int numpages, bool enc);
+DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
+
#define CPA_FLUSHTLB 1
On 05/08/2021 12:24, Robin Murphy wrote:
On 2021-06-21 17:36, John Garry wrote:
Members of struct "llq" will be zero-inited, apart from member
max_n_shift.
But we write llq.val straight after the init, so it was pointless to zero
init those other members. As such, separately init member
> -Original Message-
> From: Ard Biesheuvel [mailto:a...@kernel.org]
> Sent: 05 August 2021 14:23
> To: Shameerali Kolothum Thodi
> Cc: Linux ARM ; ACPI Devel Maling List
> ; Linux IOMMU
> ; Linuxarm ;
> Lorenzo Pieralisi ; Joerg Roedel
> ; Robin Murphy ; Will Deacon
> ; wanghuiqiang ;
在 2021/8/5 下午8:34, Yongji Xie 写道:
My main point, though, is that if you've already got something else
keeping track of the actual addresses, then the way you're using an
iova_domain appears to be something you could do with a trivial bitmap
allocator. That's why I don't buy the efficiency
On Thu, 5 Aug 2021 at 10:10, Shameer Kolothum
wrote:
>
> Hi,
>
> The series adds support to IORT RMR nodes specified in IORT
> Revision E.b -ARM DEN 0049E[0]. RMR nodes are used to describe
> memory ranges that are used by endpoints and require a unity
> mapping in SMMU.
>
> We have faced issues
On 30.07.21 04:52, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec
On Wed, Aug 4, 2021 at 11:43 PM Robin Murphy wrote:
>
> On 2021-08-04 06:02, Yongji Xie wrote:
> > On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy wrote:
> >>
> >> On 2021-08-03 09:54, Yongji Xie wrote:
> >>> On Tue, Aug 3, 2021 at 3:41 PM Jason Wang wrote:
>
>
> 在 2021/7/29 下午3:34,
On 2021-08-05 12:24, Robin Murphy wrote:
On 2021-06-21 17:36, John Garry wrote:
Members of struct "llq" will be zero-inited, apart from member
max_n_shift.
But we write llq.val straight after the init, so it was pointless to zero
init those other members. As such, separately init member
On Wed, Aug 04, 2021 at 10:59:21PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, August 4, 2021 10:05 PM
> >
> > On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
> >
> > > Can you elaborate? IMO the user only cares about the label (device cookie
> > > plus
On 2021-06-21 17:36, John Garry wrote:
Members of struct "llq" will be zero-inited, apart from member max_n_shift.
But we write llq.val straight after the init, so it was pointless to zero
init those other members. As such, separately init member max_n_shift
only.
In addition, struct "head" is
On Thu, Aug 05, 2021 at 11:22:15AM +0100, John Garry wrote:
> On 21/06/2021 17:36, John Garry wrote:
> > Members of struct "llq" will be zero-inited, apart from member max_n_shift.
> > But we write llq.val straight after the init, so it was pointless to zero
> > init those other members. As such,
On 2021-08-05 10:47, Will Deacon wrote:
If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference
to a "restricted-dma-pool" will fail with a reasonably cryptic error:
| pci-host-generic: probe of 1.pci failed with error -22
Print a more helpful message in this case and try
On 21/06/2021 17:36, John Garry wrote:
Members of struct "llq" will be zero-inited, apart from member max_n_shift.
But we write llq.val straight after the init, so it was pointless to zero
init those other members. As such, separately init member max_n_shift
only.
In addition, struct "head" is
If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference
to a "restricted-dma-pool" will fail with a reasonably cryptic error:
| pci-host-generic: probe of 1.pci failed with error -22
Print a more helpful message in this case and try to continue probing
the device as we do if
On 2021-08-04 18:15, Robin Murphy wrote:
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
v3: Also remove unneeded include
---
drivers/iommu/amd/iommu.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c
Hi Robin,
> From: Robin Murphy, Sent: Thursday, August 5, 2021 2:16 AM
>
> The core code bakes its own cookies now.
>
> CC: Yoshihiro Shimoda
> CC: Geert Uytterhoeven
> Signed-off-by: Robin Murphy
Thank you for the patch!
I tested on my environment (r8a77951-salvator-xs),
and I didn't
Hi Robin,
> From: Robin Murphy, Sent: Thursday, August 5, 2021 2:15 AM
>
> Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
> support, we can abandon the notion of drivers being responsible for the
> cookie type, and consolidate all the management into the core code.
>
> CC:
Get ACPI IORT RMR regions associated with a dev reserved
so that there is a unity mapping for them in SMMU.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/dma-iommu.c | 56 +++
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMU during probe().
Signed-off-by: Jon Nettleton
Signed-off-by:
Check if there is any RMR info associated with the devices behind
the SMMUv3 and if any, install bypass STEs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMUv3 during probe().
Signed-off-by: Shameer Kolothum
---
By default, disable_bypass flag is set and any dev without
an iommu domain installs STE with CFG_ABORT during
arm_smmu_init_bypass_stes(). Introduce a "force" flag and
move the STE update logic to arm_smmu_init_bypass_stes()
so that we can force it to install CFG_BYPASS STE for specific
SIDs.
Introduce a helper to check the sid range and to init the l2 strtab
entries(bypass). This will be useful when we have to initialize the
l2 strtab with bypass for RMR SIDs.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 28 +++--
1 file changed,
Add a helper function (iort_iommu_get_rmrs()) that retrieves RMR
memory descriptors associated with a given IOMMU. This will be used
by IOMMU drivers to setup necessary mappings.
Invoke it from the generic helper iommu_dma_get_rmrs().
Signed-off-by: Shameer Kolothum
---
Reserved Memory Regions(RMR) associated with an IOMMU can be
described through ACPI IORT tables in systems with devices
that require a unity mapping or bypass for those
regions.
Introduce a generic interface so that IOMMU drivers can retrieve
and set up necessary mappings.
Signed-off-by: Shameer
Add support for parsing RMR node information from ACPI.
Find the associated streamid and smmu node info from the
RMR node and populate a linked list with RMR memory
descriptors.
Signed-off-by: Shameer Kolothum
---
drivers/acpi/arm64/iort.c | 134 +-
1 file
A union is introduced to struct iommu_resv_region to hold
any firmware specific data. This is in preparation to add
support for IORT RMR reserve regions and the union now holds
the RMR specific information.
Signed-off-by: Shameer Kolothum
---
include/linux/iommu.h | 11 +++
1 file
Hi,
The series adds support to IORT RMR nodes specified in IORT
Revision E.b -ARM DEN 0049E[0]. RMR nodes are used to describe
memory ranges that are used by endpoints and require a unity
mapping in SMMU.
We have faced issues with 3408iMR RAID controller cards which
fail to boot when SMMU is
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Robin-Murphy/iommu-Refactor-DMA-domain-strictness/20210805-011913
base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: x86_64
On 04.08.2021 19:15, Robin Murphy wrote:
> The core code bakes its own cookies now.
>
> CC: Marek Szyprowski
> Signed-off-by: Robin Murphy
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
> ---
>
> v3: Also remove unneeded include
> ---
> drivers/iommu/exynos-iommu.c | 19
On 04.08.2021 19:15, Robin Murphy wrote:
> Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
> support, we can abandon the notion of drivers being responsible for the
> cookie type, and consolidate all the management into the core code.
>
> CC: Marek Szyprowski
> CC: Yoshihiro
在 2021/8/4 下午5:07, Yongji Xie 写道:
On Wed, Aug 4, 2021 at 4:54 PM Jason Wang wrote:
在 2021/8/4 下午4:50, Yongji Xie 写道:
On Wed, Aug 4, 2021 at 4:32 PM Jason Wang wrote:
在 2021/8/3 下午5:38, Yongji Xie 写道:
On Tue, Aug 3, 2021 at 4:09 PM Jason Wang wrote:
在 2021/7/29 下午3:34, Xie Yongji 写道:
On 06/24/21 at 11:47am, Robin Murphy wrote:
> On 2021-06-24 10:29, Baoquan He wrote:
> > On 06/24/21 at 08:40am, Christoph Hellwig wrote:
> > > So reduce the amount allocated. But the pool is needed for proper
> > > operation on systems with memory encryption. And please add the right
> > >
53 matches
Mail list logo
