On 2021/6/3 21:58, John Garry wrote:
> 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
在 2021/6/3 下午9:55, Andi Kleen 写道:
Ok, but what I meant is this, if we don't read from the descriptor
ring, and validate all the other metadata supplied by the device
(used id and len). Then there should be no way for the device to
suppress the dma flags to write to the indirect descriptor
在 2021/6/4 上午1:33, Andy Lutomirski 写道:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
an malicious host to force anything else. Also disallow
indirect mode for similar reasons.
I read
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 7:47 PM
>
> On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way the SW mode is the same as a HW mode with an infinite
> > > > >
On 2021/6/4 2:19, Jacob Pan wrote:
> Hi Shenming,
>
> On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
> wrote:
>
>> On 2021/6/2 1:33, Jason Gunthorpe wrote:
>>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
>>>
The drivers register per page table fault handlers to /dev/ioasid
For most Linux drivers, a report that a misbehaving device can corrupt
host memory is a bug, not a feature. If a USB device can corrupt kernel
memory, that's a serious bug. If a USB-C device can corrupt kernel
memory, that's also a serious bug, although, sadly, we probably have
lots of these
On 6/3/21 4:32 PM, Andi Kleen wrote:
>
>> We do not need an increasing pile of kludges
>
> Do you mean disabling features is a kludge?
>
> If yes I disagree with that characterization.
>
>
>> to make TDX and SEV “secure”. We need the actual loaded driver to be
>> secure. The virtio
在 2021/6/4 上午2:19, Jacob Pan 写道:
Hi Shenming,
On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
wrote:
On 2021/6/2 1:33, Jason Gunthorpe wrote:
On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
The drivers register per page table fault handlers to /dev/ioasid which
will then
在 2021/6/4 上午2:00, Andi Kleen 写道:
On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
an malicious host to force anything else. Also disallow
在 2021/6/4 上午3:31, Andy Lutomirski 写道:
On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
在 2021/6/3 下午9:09, Jason Gunthorpe 写道:
On Thu, Jun 03, 2021 at 10:52:51AM +0800, Jason Wang wrote:
Basically, we don't want to bother with pseudo KVM device like what VFIO
did. So for simplicity, we rules out the IOMMU that can't enforce coherency
in vhost-vDPA if the parent purely depends on
We do not need an increasing pile of kludges
Do you mean disabling features is a kludge?
If yes I disagree with that characterization.
to make TDX and SEV “secure”. We need the actual loaded driver to be secure.
The virtio architecture is full of legacy nonsense,
and there is no good
On Thu, Jun 3, 2021, at 12:53 PM, Andi Kleen wrote:
>
> > Tell that to every crypto downgrade attack ever.
>
> That's exactly what this patch addresses.
>
> >
> > I see two credible solutions:
> >
> > 1. Actually harden the virtio driver.
> That's exactly what this patchkit, and the
On Thu, 3 Jun 2021 17:10:18 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 02:01:46PM -0600, Alex Williamson wrote:
>
> > > > > 1) Mixing IOMMU_CAP_CACHE_COHERENCY and !IOMMU_CAP_CACHE_COHERENCY
> > > > >domains.
> > > > >
> > > > >This doesn't actually matter. If you mix them
Hi Parav,
On Tue, 1 Jun 2021 17:30:51 +, Parav Pandit wrote:
> > From: Tian, Kevin
> > Sent: Thursday, May 27, 2021 1:28 PM
>
> > 5.6. I/O page fault
> > +++
> >
> > (uAPI is TBD. Here is just about the high-level flow from host IOMMU
> > driver to guest IOMMU driver and
On Thu, 3 Jun 2021 09:40:36 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 03:22:27AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Thursday, June 3, 2021 10:51 AM
> > >
> > > On Wed, 2 Jun 2021 19:45:36 -0300
> > > Jason Gunthorpe wrote:
> > >
> > > > On Wed,
On Thu, Jun 03, 2021 at 02:01:46PM -0600, Alex Williamson wrote:
> > > > 1) Mixing IOMMU_CAP_CACHE_COHERENCY and !IOMMU_CAP_CACHE_COHERENCY
> > > >domains.
> > > >
> > > >This doesn't actually matter. If you mix them together then kvm
> > > >will turn on wbinvd anyhow, so we don't
On Thu, 3 Jun 2021 09:34:01 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 08:50:54PM -0600, Alex Williamson wrote:
> > On Wed, 2 Jun 2021 19:45:36 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> > >
> > > > Right. I
Tell that to every crypto downgrade attack ever.
That's exactly what this patch addresses.
I see two credible solutions:
1. Actually harden the virtio driver.
That's exactly what this patchkit, and the alternative approaches, like
Jason's, are doing.
2. Have a new virtio-modern driver
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
> this is a set of patches that is the result of earlier discussions
> regarding early identity mappings that are needed to avoid SMMU faults
> during early boot.
>
> The goal here is to avoid early identity mappings altogether and instead
On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
>
> On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
> > On 6/2/21 5:41 PM, Andi Kleen wrote:
> >> Only allow split mode when in a protected guest. Followon
> >> patches harden the split mode code paths, and we don't want
> >> an malicious host to
tree: https://github.com/AsahiLinux/linux dart/dev
head: 1bc74c306de810171ce90d15c42ac846bbf183dc
commit: df7d638f551bba7275f5deedee488db2b7fbcc51 [1/4] iommu/dma: Fix IOVA
reserve dma ranges
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce
Hi Shenming,
On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
wrote:
> On 2021/6/2 1:33, Jason Gunthorpe wrote:
> > On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
> >
> >> The drivers register per page table fault handlers to /dev/ioasid which
> >> will then register itself to iommu
On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
an malicious host to force anything else. Also disallow
indirect mode for similar reasons.
I
On 6/2/21 5:41 PM, Andi Kleen wrote:
> Only allow split mode when in a protected guest. Followon
> patches harden the split mode code paths, and we don't want
> an malicious host to force anything else. Also disallow
> indirect mode for similar reasons.
I read this as "the virtio driver is buggy.
On 6/2/21 1:37 PM, Luck, Tony wrote:
>>> ... so on a PASID system, your trivial reproducer would theoretically
>>> fire the same way and corrupt FPU state just as well.
>>
>> This is worse and you can't selftest it because the IPI can just hit in
>> the middle of _any_ FPU state operation and
On 6/3/21 11:37 AM, Tianyu Lan wrote:
>
> Yes, the dependency is between hyperv_swiotlb_detect() and
> pci_swiotlb_detect_override()/pci_swiotlb_detect_4gb(). Now
> pci_swiotlb_detect_override() and pci_swiotlb_detect_4gb() depends on
> pci_xen_swiotlb_detect(). To keep dependency between
>
On 03/06/2021 18:00, Randy Dunlap wrote:
+config IOMMU_DEFAULT_STRICT
+ bool "strict"
+ help
+ For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+ the free operation of IOVA are guaranteed to be done in the unmap
+ function.
+
+
On 6/3/21 6:58 AM, John Garry wrote:
> 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
From: Thierry Reding
Add the device tree node for the dual-SMMU found on Tegra194 and hook up
peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86
1 file changed, 86 insertions(+)
From: Thierry Reding
On Tegra186 and later, the memory controller needs to be programmed in
coordination with any of the ARM SMMU instances to configure the stream
ID used for each memory client.
To support this, add a phandle reference to the memory controller to the
SMMU device tree node.
From: Thierry Reding
The SMMU found on Tegra186 requires interoperation with the memory
controller in order to program stream ID overrides. The generic ARM SMMU
500 compatible is therefore inaccurate. Replace it with a more correct,
SoC-specific compatible string.
Signed-off-by: Thierry Reding
From: Thierry Reding
Tegra186 requires the same SID override programming as Tegra194 in order
to seamlessly transition from the firmware framebuffer to the Linux
framebuffer, so the Tegra implementation needs to be used on Tegra186
devices as well.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
The secure firmware keeps some SID override registers set as passthrough
in order to allow devices such as the display controller to operate with
no knowledge of SMMU translations until an operating system driver takes
over. This is needed in order to seamlessly transition
From: Thierry Reding
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding
---
Changes in v2:
- remove unnecessarily paranoid check
From: Thierry Reding
Parse the reg property in device tree and detect the number of instances
represented by a device tree node. This is subsequently needed in order
to support single-instance SMMUs with the Tegra implementation because
additional programming is needed to properly configure the
From: Thierry Reding
The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.
Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this,
From: Thierry Reding
Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and programs the SID specified in device tree, which
From: Thierry Reding
Hi,
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity
On 6/3/2021 12:02 AM, Boris Ostrovsky wrote:
On 6/2/21 11:01 AM, Tianyu Lan wrote:
Hi Boris:
Thanks for your review.
On 6/2/2021 9:16 AM, Boris Ostrovsky wrote:
On 5/30/21 11:06 AM, Tianyu Lan wrote:
@@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
On Thu, Jun 03, 2021 at 06:17:04PM +0530, Vinod Koul wrote:
> You can add:
>
> Acked-By: Vinod Koul
Done.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
iommu mailing list
From: Zhen Lei
The default DMA mode is lazy, but allow this to be set to strict mode at
build time. It may still be overridden by the relevant boot option.
Also make IOMMU_DEFAULT_LAZY default for when AMD_IOMMU config is set.
[jpg: Rebase for relocated file]
Signed-off-by: Zhen Lei
From: Zhen Lei
Make IOMMU_DEFAULT_LAZY default for when INTEL_IOMMU config is set,
and make intel_iommu_strict initially hold value of
IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT).
Signed-off-by: Zhen Lei
Signed-off-by: John Garry
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel/iommu.c
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
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
Ok, but what I meant is this, if we don't read from the descriptor
ring, and validate all the other metadata supplied by the device (used
id and len). Then there should be no way for the device to suppress
the dma flags to write to the indirect descriptor table.
Or do you have an example
Now that DMA ops are part of the core API via iommu-dma, fold the
vestigial remains of the IOMMU_DMA_OPS init state into the IOMMU API
phase, and clean up a few other leftovers. This should also close the
race window wherein bus_set_iommu() effectively makes the DMA ops state
visible before its
On 2021-06-03 13:32, Jussi Maki wrote:
On Wed, Jun 2, 2021 at 2:49 PM Robin Murphy wrote:
Thanks for the quick response & patch. I tried it out and indeed it
does solve the issue:
Cool, thanks Jussi. May I infer a Tested-by tag from that?
Of course!
Given that the race looks to have been
On Thu, Jun 03, 2021 at 10:52:51AM +0800, Jason Wang wrote:
> Basically, we don't want to bother with pseudo KVM device like what VFIO
> did. So for simplicity, we rules out the IOMMU that can't enforce coherency
> in vhost-vDPA if the parent purely depends on the platform IOMMU:
VDPA HW cannot
On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > >
> > > struct attach_info {
> > > u32 ioasid;
> > > // If valid, the PASID to be used physically
> > > u32 pasid;
> > >
From: Joerg Roedel
Add this option to enable the IOMMU on platforms like AMD Stoney,
where the kernel usually disables it because it may cause problems in
some scenarios.
Signed-off-by: Joerg Roedel
Acked-by: Alex Deucher
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
On Thu, Jun 03, 2021 at 02:50:11PM +0800, Lu Baolu wrote:
> Hi David,
>
> On 6/3/21 1:54 PM, David Gibson wrote:
> > On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
> > > Hi Jason,
> > >
> > > On 2021/5/29 7:36, Jason Gunthorpe wrote:
> > > > > /*
> > > > > * Bind an user-managed
On 2021-06-03 13:24, Peter Geis wrote:
On Thu, Jun 3, 2021 at 8:07 AM Robin Murphy wrote:
On 2021-05-27 03:37, x...@rock-chips.com wrote:
Hi all,
I have a SoC integrate with two different types of iommus, one is ARM SMMU,
serves the PCIe/SATA/USB,
the others are vendor specific iommus,
On Thu, Jun 03, 2021 at 07:17:23AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Wednesday, June 2, 2021 2:15 PM
> >
> [...]
> > > An I/O address space takes effect in the IOMMU only after it is attached
> > > to a device. The device in the /dev/ioasid context always refers to a
>
On 03-06-21, 13:42, Borislav Petkov wrote:
> On Thu, Jun 03, 2021 at 04:50:26PM +0530, Vinod Koul wrote:
> > Applied, thanks
>
> Actually, I'd prefer if I take it through the tip tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent
>
> because it is needed for
On Thu, Jun 03, 2021 at 04:26:08PM +1000, David Gibson wrote:
> > There are global properties in the /dev/iommu FD, like what devices
> > are part of it, that are important for group security operations. This
> > becomes confused if it is split to many FDs.
>
> I'm still not seeing those. I'm
On Thu, Jun 03, 2021 at 03:22:27AM +, Tian, Kevin wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 3, 2021 10:51 AM
> >
> > On Wed, 2 Jun 2021 19:45:36 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> > >
> > > > Right.
What it looks like to me is abusing SWIOTLB's internal housekeeping to
keep track of virtio-specific state. The DMA API does not attempt to
validate calls in general since in many cases the additional overhead
would be prohibitive. It has always been callers' responsibility to
keep track
On Wed, Jun 02, 2021 at 08:50:54PM -0600, Alex Williamson wrote:
> On Wed, 2 Jun 2021 19:45:36 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> >
> > > Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> > > from the guest
On Wed, Jun 2, 2021 at 2:49 PM Robin Murphy wrote:
> >> Thanks for the quick response & patch. I tried it out and indeed it
> >> does solve the issue:
>
> Cool, thanks Jussi. May I infer a Tested-by tag from that?
Of course!
> Given that the race looks to have been pretty theoretical until now,
Hi Jon,
On 6/3/2021 3:27 PM, Jon Nettleton wrote:
> On Wed, May 26, 2021 at 7:11 PM Laurentiu Tudor
> wrote:
>>
>>
>>
>> On 5/26/2021 7:36 PM, Shameerali Kolothum Thodi wrote:
>>>
>>>
-Original Message-
From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com]
Sent: 26 May
On Thu, Jun 03, 2021 at 03:23:17PM +1000, David Gibson wrote:
> On Wed, Jun 02, 2021 at 01:37:53PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 02, 2021 at 04:57:52PM +1000, David Gibson wrote:
> >
> > > I don't think presence or absence of a group fd makes a lot of
> > > difference to this
On Wed, May 26, 2021 at 7:11 PM Laurentiu Tudor wrote:
>
>
>
> On 5/26/2021 7:36 PM, Shameerali Kolothum Thodi wrote:
> >
> >
> >> -Original Message-
> >> From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com]
> >> Sent: 26 May 2021 08:53
> >> To: Shameerali Kolothum Thodi ;
> >>
On Thu, Jun 3, 2021 at 8:07 AM Robin Murphy wrote:
>
> On 2021-05-27 03:37, x...@rock-chips.com wrote:
> > Hi all,
> >
> > I have a SoC integrate with two different types of iommus, one is ARM SMMU,
> > serves the PCIe/SATA/USB,
> > the others are vendor specific iommus, serves display device
On Thu, Jun 03, 2021 at 03:45:09PM +1000, David Gibson wrote:
> On Wed, Jun 02, 2021 at 01:58:38PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > > /* Bind guest I/O page table */
> > > > > bind_data = {
> > > > >
On 2021-05-27 03:37, x...@rock-chips.com wrote:
Hi all,
I have a SoC integrate with two different types of iommus, one is ARM SMMU,
serves the PCIe/SATA/USB,
the others are vendor specific iommus, serves display device and multimedia
device.
In the current linux kernel, the iommu framework
On Thu, Jun 03, 2021 at 03:13:44PM +1000, David Gibson wrote:
> > We can still consider it a single "address space" from the IOMMU
> > perspective. What has happened is that the address table is not just a
> > 64 bit IOVA, but an extended ~80 bit IOVA formed by "PASID, IOVA".
>
> True. This
On Thu, Jun 3, 2021 at 1:27 PM Steven Price wrote:
>
> On 03/06/2021 09:52, Jon Nettleton wrote:
> > On Mon, May 24, 2021 at 1:04 PM Shameer Kolothum
> > wrote:
> >>
> >> From: Jon Nettleton
> >>
> >> Check if there is any RMR info associated with the devices behind
> >> the SMMU and if any,
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 03 June 2021 12:37
> To: Shameerali Kolothum Thodi
> Cc: linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org; Linuxarm ;
>
On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Thursday, June 3, 2021 1:09 PM
> [...]
> > > > In this way the SW mode is the same as a HW mode with an infinite
> > > > cache.
> > > >
> > > > The collaposed shadow page table is really just a cache.
> >
On Thu, Jun 03, 2021 at 04:50:26PM +0530, Vinod Koul wrote:
> Applied, thanks
Actually, I'd prefer if I take it through the tip tree:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent
because it is needed for the following patch by tglx:
6867ee8bcb75
On Thu, May 13, 2021 at 02:45:43PM +0100, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream id and smmu node info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
"Add support for parsing RMR node information
On 03/06/2021 09:52, Jon Nettleton wrote:
> On Mon, May 24, 2021 at 1:04 PM Shameer Kolothum
> wrote:
>>
>> 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
On Thu, May 13, 2021 at 02:45:45PM +0100, Shameer Kolothum wrote:
> Add a helper function that retrieves RMR memory descriptors
> associated with a given IOMMU. This will be used by IOMMU
> drivers to setup necessary mappings.
>
> Now that we have this, invoke it from the generic helper
"Add a
On 02-06-21, 12:14, Borislav Petkov wrote:
> ---
> From: Borislav Petkov
> Date: Wed, 2 Jun 2021 12:07:52 +0200
> Subject: [PATCH] dmaengine: idxd: Use cpu_feature_enabled()
>
> When testing x86 feature bits, use cpu_feature_enabled() so that
> build-disabled features can remain off, regardless
On 2021-06-02 21:18, Sven Peter wrote:
Hi,
I just ran into the exact same issue while working on the M1 DART IOMMU driver
and it was fixed by this commit. Thanks!
Would be great if this could be picked up.
Oops, apparently I was happy enough with this 9 months ago to forget
about it, so if
On 2021-06-03 10:17, Tvrtko Ursulin wrote:
Hi,
On 03/06/2021 09:40, Joonas Lahtinen wrote:
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
Hi all,
swiotlb_max_segment is a rather strange "API"
Hi,
On 03/06/2021 09:40, Joonas Lahtinen wrote:
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
Hi all,
swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
and i915 is the only
On 2021-06-03 01:41, Andi Kleen wrote:
swiotlb currently only uses the start address of a DMA to check if something
is in the swiotlb or not. But with virtio and untrusted hosts the host
could give some DMA mapping that crosses the swiotlb boundaries,
potentially leaking or corrupting data. Add
Hi Andi,
On 2021-06-03 01:41, Andi Kleen wrote:
In some situations when we know swiotlb is forced and we have
to deal with untrusted hosts, it's useful to know if a mapping
was in the swiotlb or not. This allows us to abort any IO
operation that would access memory outside the swiotlb.
On Mon, May 24, 2021 at 1:04 PM Shameer Kolothum
wrote:
>
> 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
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Signed-off-by: Sven Peter
---
MAINTAINERS | 1 +
drivers/iommu/Kconfig| 15 +
drivers/iommu/Makefile
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Signed-off-by: Sven Peter
---
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Signed-off-by: Sven Peter
---
.../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
MAINTAINERS | 6 ++
2 files changed, 87 insertions(+)
create mode
Hi,
This is v3 of my Apple M1 DART IOMMU driver series as a follow up to the
original
two versions [1][2].
Short summary: this series adds support for the iommu found in Apple's new M1
SoC which is required to use DMA on most peripherals. So far this code has been
tested with dwc3 in host and
It is only used inside the loop and the old value is not reused.
Signed-off-by: Rolf Eike Beer
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index be35284a2016..fa262b805dd6 100644
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> >
> >
> From: David Gibson
> Sent: Wednesday, June 2, 2021 2:15 PM
>
[...]
> >
> > /*
> > * Get information about an I/O address space
> > *
> > * Supported capabilities:
> > * - VFIO type1 map/unmap;
> > * - pgtable/pasid_table binding
> > * - hardware nesting vs. software nesting;
> >
On 03/06/2021 01:39, Lu Baolu wrote:
I did actually try increasing the range for a 'live' domain in the v1
series, but it turned out too messy. First problem is reallocating the
memory to hold the rcaches. Second problem is that we need to deal
with the issue that all IOVAs in the rcache need
On Thu, Jun 03, 2021 at 04:06:18AM +0800, kernel test robot wrote:
> >> drivers/acpi/scan.c:1540:26: error: no member named 'ops' in 'struct
> >> iommu_fwspec'
>return fwspec ? fwspec->ops : NULL;
>~~ ^
> >> drivers/acpi/scan.c:1564:9: error: implicit
> From: David Gibson
> Sent: Wednesday, June 2, 2021 2:15 PM
>
[...]
> > An I/O address space takes effect in the IOMMU only after it is attached
> > to a device. The device in the /dev/ioasid context always refers to a
> > physical one or 'pdev' (PF or VF).
>
> What you mean by "physical"
Hi David,
On 6/3/21 1:54 PM, David Gibson wrote:
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
Hi Jason,
On 2021/5/29 7:36, Jason Gunthorpe wrote:
/*
* Bind an user-managed I/O page table with the IOMMU
*
* Because user page table is untrusted, IOASID nesting must be
> From: David Gibson
> Sent: Thursday, June 3, 2021 1:09 PM
[...]
> > > In this way the SW mode is the same as a HW mode with an infinite
> > > cache.
> > >
> > > The collaposed shadow page table is really just a cache.
> > >
> >
> > OK. One additional thing is that we may need a 'caching_mode"
>
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 7:37 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
> > *
> > * This is for FD-level capabilities,
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
> Hi Jason,
>
> On 2021/5/29 7:36, Jason Gunthorpe wrote:
> > > /*
> > >* Bind an user-managed I/O page table with the IOMMU
> > >*
> > >* Because user page table is untrusted, IOASID nesting must be enabled
> > >* for this
On Wed, Jun 02, 2021 at 02:19:30PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:15:07PM +1000, David Gibson wrote:
>
> > Is there a compelling reason to have all the IOASIDs handled by one
> > FD?
>
> There was an answer on this, if every PASID needs an IOASID then there
> are too
On Wed, Jun 02, 2021 at 01:16:48PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:32:27PM +1000, David Gibson wrote:
> > > I agree with Jean-Philippe - at the very least erasing this
> > > information needs a major rational - but I don't really see why it
> > > must be erased? The HW
On Wed, Jun 02, 2021 at 01:58:38PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > /* Bind guest I/O page table */
> > > > bind_data = {
> > > > .ioasid = gva_ioasid;
> > > > .addr =
On Thu, Jun 03, 2021 at 02:49:56AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 12:59 AM
> >
> > On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > > /* Bind guest I/O page table */
> > > > > bind_data = {
> > > > >
On Wed, Jun 02, 2021 at 01:37:53PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:57:52PM +1000, David Gibson wrote:
>
> > I don't think presence or absence of a group fd makes a lot of
> > difference to this design. Having a group fd just means we attach
> > groups to the ioasid
1 - 100 of 101 matches
Mail list logo
