On Tue, 2021-12-14 at 17:04 +0800, Tzung-Bi Shih wrote:
> On Tue, Dec 14, 2021 at 03:31:25PM +0800, Yong Wu wrote:
> > On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
> > > Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for
> > > smi-
> > > common
> > > and m4u"), the driver
On Tue, 2021-12-14 at 07:02 -0800, Guenter Roeck wrote:
> On 12/13/21 11:31 PM, Yong Wu wrote:
> > On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
> > > Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for
> > > smi-
> > > common
> > > and m4u"), the driver assumes that at least
On 12/15/2021 6:40 AM, Dave Hansen wrote:
On 12/14/21 2:23 PM, Tom Lendacky wrote:
I don't really understand how this can be more general any *not* get
utilized by the existing SEV support.
The Virtual Top-of-Memory (VTOM) support is an SEV-SNP feature that is
meant to be used with a
On Tue, Dec 14, 2021 at 03:43:35PM +0100, Vlastimil Babka wrote:
> On 12/14/21 15:38, Hyeonggon Yoo wrote:
> > On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote:
> >> On 12/1/21 19:14, Vlastimil Babka wrote:
> >> > Folks from non-slab subsystems are Cc'd only to patches affecting
On 2021/12/14 22:48, Will Deacon wrote:
> On Tue, Dec 07, 2021 at 02:32:48PM +0800, Zhou Wang wrote:
>> The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of
>> evtq and priq") decreases evtq and priq, which may lead evtq/priq to be
>> full with fault events, e.g HiSilicon
On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote:
> On 12/1/21 19:14, Vlastimil Babka wrote:
> > Folks from non-slab subsystems are Cc'd only to patches affecting them, and
> > this cover letter.
> >
> > Series also available in git, based on 5.16-rc3:
> >
On 12/14/21 2:23 PM, Tom Lendacky wrote:
>> I don't really understand how this can be more general any *not* get
>> utilized by the existing SEV support.
>
> The Virtual Top-of-Memory (VTOM) support is an SEV-SNP feature that is
> meant to be used with a (relatively) un-enlightened guest. The
On 12/14/21 12:40 PM, Dave Hansen wrote:
On 12/13/21 8:36 PM, Tianyu Lan wrote:
On 12/14/2021 12:45 AM, Dave Hansen wrote:
On 12/12/21 11:14 PM, Tianyu Lan wrote:
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary (E.G
Nishanth,
On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
> On 21:15-20211214, Thomas Gleixner wrote:
>> I think I managed to distangle this. Can you please give:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2
>
>
> Umm
On 21:15-20211214, Thomas Gleixner wrote:
> Nishanth,
>
> On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote:
> > msi_device_data_release()
> > ...
> > pcim_release()
> >pci_disable_msi[x]()
> >
> > Groan
>
> I thi
Nishanth,
On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote:
> msi_device_data_release()
> ...
> pcim_release()
>pci_disable_msi[x]()
>
> Groan
I think I managed to distangle this. Can you please give:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git
On 12/13/21 8:36 PM, Tianyu Lan wrote:
> On 12/14/2021 12:45 AM, Dave Hansen wrote:
>> On 12/12/21 11:14 PM, Tianyu Lan wrote:
>>> In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
>>> extra address space which is above shared_gpa_boundary (E.G 39 bit
>>> address line) reported
From: Tianyu Lan Sent: Sunday, December 12, 2021 11:14 PM
>
> Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
> security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
> is to add support for these Isolation VM support in Linux.
>
> The memory of these vms are
On 2021-12-14 17:18, John Garry via iommu wrote:
On 10/12/2021 17:54, Robin Murphy wrote:
+ iovad->fq_domain = fq_domain;
+ iovad->fq = queue;
+
+ timer_setup(>fq_timer, fq_flush_timeout, 0);
+ atomic_set(>fq_timer_on, 0);
+
+ return 0;
+}
+
+
nit: a single blank line is
On 10/12/2021 17:54, Robin Murphy wrote:
+ iovad->fq_domain = fq_domain;
+ iovad->fq = queue;
+
+ timer_setup(>fq_timer, fq_flush_timeout, 0);
+ atomic_set(>fq_timer_on, 0);
+
+ return 0;
+}
+
+
nit: a single blank line is standard, I think
Cheers
static
On 10/12/2021 17:54, Robin Murphy wrote:
Complete the move into iommu-dma by refactoring the flush queues
themselves to belong to the DMA cookie rather than the IOVA domain.
The refactoring may as well extend to some minor cosmetic aspects
too, to help us stay one step ahead of the style
On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
>> On 10:41-20211214, Thomas Gleixner wrote:
> [ 13.478122] Call trace:
> [ 13.509042] msi_device_destroy_sysfs+0x18/0x88
> [ 13.509058] msi_domain_free_irqs+0x34/0x
On 10/12/2021 17:54, Robin Murphy wrote:
Flush queues are specific to DMA ops, which are now handled exclusively
by iommu-dma. As such, now that the historical artefacts from being
shared directly with drivers have been cleaned up, move the flush queue
code into iommu-dma itself to get it out of
On 10/12/2021 17:54, Robin Murphy wrote:
Squash and simplify some of the freeing code, and move the init
and free routines down into the rest of the flush queue code to
obviate the forward declarations.
It would be good to get rid of all of these eventually...
Signed-off-by: Robin Murphy
On 10/12/2021 17:54, Robin Murphy wrote:
Once again, with iommu-dma now being the only flush queue user, we no
longer need the extra level of indirection through flush_cb. Squash that
and let the flush queue code call the domain method directly.
Signed-off-by: Robin Murphy
Again seems pretty
On 10/12/2021 17:54, Robin Murphy wrote:
All flush queues are driven by iommu-dma now, so there is no need to
abstract entry_dtor or its data any more. Squash the now-canonical
implementation directly into the IOVA code to get it out of the way.
Signed-off-by: Robin Murphy
Seems pretty
On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
> On 10:41-20211214, Thomas Gleixner wrote:
> Agreed that the warning is fine, the null pointer exception that follows
> [1] [2] it however does'nt look right and it can be trivially fixed with the
> following fixup for ee90787487bc
This approach looks much better to me.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 10:41-20211214, Thomas Gleixner wrote:
> On Mon, Dec 13 2021 at 12:29, Nishanth Menon wrote:
> > On 23:18-20211210, Thomas Gleixner wrote:
> > Also while testing on TI K3 platforms, I noticed:
> >
> > msi_device_data_release/msi_device_destroy_sysfs in am64xx-e
On 2021-11-08 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when programming engines
On Tue, Oct 05, 2021 at 08:16:25AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add an io-pgtable method to retrieve the raw PTEs that would be
> traversed for a given iova access.
>
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/io-pgtable-arm.c | 40 +++---
>
On Mon, Dec 13, 2021 at 02:14:03AM -0500, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides Isolation VM for confidential computing support and
> guest memory is encrypted in it. Places checking cc_platform_has()
> with GUEST_MEM_ENCRYPT attr should return "True" in Isolation vm. e.g,
>
14.12.2021 17:53, Mikko Perttunen пишет:
> On 12/14/21 16:35, Dmitry Osipenko wrote:
>> 14.12.2021 11:05, Jon Hunter пишет:
>>> Hi all,
>>>
>>> Still no response on this :-(
>>
>> I see only two patches on Tegra ML and others on DRI ML. Might be good
>> to start with re-sending this whole series
On Tue, 7 Dec 2021 19:33:15 +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> In __arm_v7s_alloc_table function:
> iommu call kmem_cache_alloc to allocate page table, this function
> allocate memory may fail, when kmem_cache_alloc fails to allocate
> table, call virt_to_phys will be
On Wed, 1 Dec 2021 13:09:41 +0530, Vinod Koul wrote:
> This adds the binding and support for IOMMU found in SM8450 SoC
>
> Vinod Koul (2):
> dt-bindings: arm-smmu: Add compatible for SM8450 SoC
> iommu: arm-smmu-impl: Add SM8450 qcom iommu implementation
>
>
On Mon, 8 Nov 2021 09:17:23 -0800, Rob Clark wrote:
> From: Rob Clark
>
> It is a 64b register, lets not lose the upper bits.
>
>
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Fix TTBR0 read
https://git.kernel.org/will/c/c31112fbd407
Cheers,
--
Will
On Sat, 4 Dec 2021 23:33:01 +0100, Rikard Falkeborn wrote:
> The only usage of arm_smmu_mmu_notifier_ops is to assign its address to
> the ops field in the mmu_notifier struct, which is a pointer to const
> struct mmu_notifier_ops. Make it const to allow the compiler to put it
> in read-only
On Thu, 21 Oct 2021 01:17:00 +0200, David Heidelberg wrote:
> Add missing compatible for the SDX55 SoC.
>
>
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] dt-bindings: arm-smmu: Add compatible for the SDX55 SoC
https://git.kernel.org/will/c/ae377d342006
Cheers,
--
Will
On 2021-12-14 14:48, Will Deacon wrote:
On Tue, Dec 07, 2021 at 02:32:48PM +0800, Zhou Wang wrote:
The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of
evtq and priq") decreases evtq and priq, which may lead evtq/priq to be
full with fault events, e.g HiSilicon ZIP/SEC/HPRE
On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote:
> On 12/1/21 19:14, Vlastimil Babka wrote:
> > Folks from non-slab subsystems are Cc'd only to patches affecting them, and
> > this cover letter.
> >
> > Series also available in git, based on 5.16-rc3:
> >
On Tue, Dec 14, 2021 at 03:31:25PM +0800, Yong Wu wrote:
> On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
> > Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for smi-
> > common
> > and m4u"), the driver assumes that at least one phandle associated
> > with
> >
On 12/13/21 11:31 PM, Yong Wu wrote:
On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for smi-
common
and m4u"), the driver assumes that at least one phandle associated
with
"mediatek,larbs" exists. If that is not the case, for
On 12/14/21 16:35, Dmitry Osipenko wrote:
14.12.2021 11:05, Jon Hunter пишет:
Hi all,
Still no response on this :-(
I see only two patches on Tegra ML and others on DRI ML. Might be good
to start with re-sending this whole series and CCing MLs properly.
All patches should have been sent
On Tue, Dec 07, 2021 at 02:32:48PM +0800, Zhou Wang wrote:
> The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of
> evtq and priq") decreases evtq and priq, which may lead evtq/priq to be
> full with fault events, e.g HiSilicon ZIP/SEC/HPRE have maximum 1024 queues
> in one
On 12/14/21 15:38, Hyeonggon Yoo wrote:
> On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote:
>> On 12/1/21 19:14, Vlastimil Babka wrote:
>> > Folks from non-slab subsystems are Cc'd only to patches affecting them, and
>> > this cover letter.
>> >
>> > Series also available in git,
14.12.2021 11:05, Jon Hunter пишет:
> Hi all,
>
> Still no response on this :-(
I see only two patches on Tegra ML and others on DRI ML. Might be good
to start with re-sending this whole series and CCing MLs properly.
___
iommu mailing list
On Wed, 17 Nov 2021 14:48:42 +, Jean-Philippe Brucker wrote:
> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
> multiple independent PMCGs, for example one for the Translation Control
> Unit (TCU)
On 12/1/21 19:14, Vlastimil Babka wrote:
> Folks from non-slab subsystems are Cc'd only to patches affecting them, and
> this cover letter.
>
> Series also available in git, based on 5.16-rc3:
> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v2r2
Pushed
On Mon, Dec 13 2021 at 12:29, Nishanth Menon wrote:
> On 23:18-20211210, Thomas Gleixner wrote:
> Also while testing on TI K3 platforms, I noticed:
>
> msi_device_data_release/msi_device_destroy_sysfs in am64xx-evm / j7200
The warning complains about a device being released with MSI descriptors
Hi all,
Still no response on this :-(
On 06/12/2021 09:55, Jon Hunter wrote:
Will, Joerg, Rob,
On 08/11/2021 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom
45 matches
Mail list logo
