On 11/07/17 20:39, Robin Murphy wrote:
> On 10/07/17 20:23, Bjorn Helgaas via iommu wrote:
>> [+cc Joerg, iommu]
>>
>> On Fri, Jun 30, 2017 at 12:24 AM, Alexey Kardashevskiy
>> wrote:
>>> From: Yongji Xie
>>>
>>> Some iommu drivers wou
On 11/07/17 05:23, Bjorn Helgaas wrote:
> [+cc Joerg, iommu]
>
> On Fri, Jun 30, 2017 at 12:24 AM, Alexey Kardashevskiy wrote:
>> From: Yongji Xie
>>
>> Some iommu drivers would be initialized after PCI device
>> enumeration. So PCI_BUS_FLAGS_MSI_REMAP wou
On 19/07/17 20:02, Alexey Kardashevskiy wrote:
> On 11/07/17 05:23, Bjorn Helgaas wrote:
>> [+cc Joerg, iommu]
>>
>> On Fri, Jun 30, 2017 at 12:24 AM, Alexey Kardashevskiy
>> wrote:
>>> From: Yongji Xie
>>>
>>> Some iommu drivers wou
before PCI scan begins.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ddbdaca..1065a1a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -861,7
Hi!
On POWERNV we use only the part of IOMMU API which handles devices and
groups. We do not use IOMMU domains as VFIO containers do everything we
need for VFIO and we do not implement iommu_ops as it is not very relevant
to our architecture (does not give dma window properties, etc).
So you
.
Regards
Varun
-Original Message-
From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
Sent: Friday, March 01, 2013 6:55 AM
To: Kumar Gala
Cc: Sethi Varun-B16395; Benjamin Herrenschmidt; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org list; linux-
ker...@vger.kernel.org list
in order
to support in-kernel handling of DMA map/unmap requests.
The patch adds the iommu_group_find(id) function which performs
such search.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 26 ++
include/linux/iommu.h |1 +
2 files changed, 27
in order
to support in-kernel handling of DMA map/unmap requests.
The patch adds the iommu_group_get_by_id(id) function which performs
such search.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 28
include/linux/iommu.h |1 +
2 files changed
in order
to support in-kernel handling of DMA map/unmap requests.
The patch adds the iommu_group_get_by_id(id) function which performs
such search.
v2: fixed reference counting.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 29 +
include/linux
On 10/10/2018 00:24, Christoph Hellwig wrote:
> This code has been unused since it was merged and is in the way of
> cleaning up the DMA code, thus remove it.
>
> This effectively reverts commit 5d2aa710 ("powerpc/powernv: Add support
> for Nvlink NPUs").
This code is heavily used by the NVIDI
On 21/03/2020 01:16, Christoph Hellwig wrote:
> Several IOMMU drivers have a bypass mode where they can use a direct
> mapping if the devices DMA mask is large enough. Add generic support
> to the core dma-mapping code to do that to switch those drivers to
> a common solution.
>
> Signed-off-b
On 23/03/2020 19:37, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 12:28:34PM +1100, Alexey Kardashevskiy wrote:
>
> [full quote deleted, please follow proper quoting rules]
>
>>> +static bool dma_alloc_direct(struct device *dev, const struct dma_map_ops
>&g
On 24/03/2020 04:22, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>>
>> This is what I was trying, but considering I am new to DMA subsystem, I
>> am not sure I got all the details correct. The idea is to look at the
>> cpu addr and see if that can
On 24/03/2020 04:20, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 07:58:01PM +1100, Alexey Kardashevskiy wrote:
>>>> 0x100.. .. 0x101..
>>>>
>>>> 2x4G, each is 1TB aligned. And we can map directly only the first 4GB
>>>>
On 24/03/2020 14:37, Alexey Kardashevskiy wrote:
>
>
> On 24/03/2020 04:20, Christoph Hellwig wrote:
>> On Mon, Mar 23, 2020 at 07:58:01PM +1100, Alexey Kardashevskiy wrote:
>>>>> 0x100.. .. 0x101..
>>>>>
>>>>> 2x4G,
On 24/03/2020 18:54, Christoph Hellwig wrote:
> On Tue, Mar 24, 2020 at 02:05:54PM +1100, Alexey Kardashevskiy wrote:
>> This is for persistent memory which you can DMA to/from but yet it does
>> not appear in the system as a normal memory and therefore requires
>> sp
On 25/03/2020 19:37, Christoph Hellwig wrote:
> On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote:
>>>> This is for persistent memory which you can DMA to/from but yet it does
>>>> not appear in the system as a normal memory and therefore requires
&
On 26/03/2020 12:26, Alexey Kardashevskiy wrote:
>
>
> On 25/03/2020 19:37, Christoph Hellwig wrote:
>> On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote:
>>>>> This is for persistent memory which you can DMA to/from but yet it does
>&
On 06/04/2020 21:50, Christoph Hellwig wrote:
> On Fri, Apr 03, 2020 at 07:38:11PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 26/03/2020 12:26, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 25/03/2020 19:37, Christoph Hellwig wrote:
>&
On 07/04/2020 03:17, Christoph Hellwig wrote:
> On Mon, Apr 06, 2020 at 11:25:09PM +1000, Alexey Kardashevskiy wrote:
>>>> Do you see any serious problem with this approach? Thanks!
>>>
>>> Do you have a link to the whole branch? The github UI is unfortunat
On 07/04/2020 20:12, Alexey Kardashevskiy wrote:
>
>
> On 07/04/2020 03:17, Christoph Hellwig wrote:
>> On Mon, Apr 06, 2020 at 11:25:09PM +1000, Alexey Kardashevskiy wrote:
>>>>> Do you see any serious problem with this approach? Thanks!
>>>>
>>
On 14/04/2020 22:25, Christoph Hellwig wrote:
> For a long time the DMA API has been implemented inline in dma-mapping.h,
> but the function bodies can be quite large. Move them all out of line.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/dma-direct.h | 58 +
> inclu
On 15/04/2020 16:18, Christoph Hellwig wrote:
> On Wed, Apr 15, 2020 at 12:26:04PM +1000, Alexey Kardashevskiy wrote:
>> May be this is correct and allowed (no idea) but removing exported
>> symbols at least deserves a mention in the commit log, does not it?
>>
>> The
On 19/04/2020 22:25, Joerg Roedel wrote:
> On Sun, Apr 19, 2020 at 10:00:58AM +0200, Christoph Hellwig wrote:
>> The difference is that NULL ops mean imply the direct mapping is always
>> used, dma_ops_bypass means a direct mapping is used if no bounce buffering
>> using swiotlb is needed, which
On 17/04/2020 17:58, Christoph Hellwig wrote:
> On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
>> And the fact they were exported leaves possibility that there is a
>> driver somewhere relying on these symbols or distro kernel won't build
>> beca
On 09/05/2020 18:19, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 17/04/2020 17:58, Christoph Hellwig wrote:
>>> On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
>>>&
On 09/05/2020 18:19, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 17/04/2020 17:58, Christoph Hellwig wrote:
>>> On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
>>>&
On 27/06/12 22:37, Dan Carpenter wrote:
> On Mon, Jun 25, 2012 at 10:55:52PM -0600, Alex Williamson wrote:
>> Hi,
>>
>> VFIO has been kicking around for well over a year now and has been
>> posted numerous times for review. The pre-requirements are finally
>> available in linux-next (or will be in
On 16/12/12 22:20, Joerg Roedel wrote:
Alexey,
On Thu, Dec 13, 2012 at 08:48:55AM -0700, Alex Williamson wrote:
Probably a good idea to CC the iommu list and maintainer...
On Thu, 2012-12-13 at 17:28 +1100, Alexey Kardashevskiy wrote:
Signed-off-by: Alexey Kardashevskiy
Please resend the
On 04/18/2016 08:56 PM, Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.
This is because vfio will not allow to passthrough one BAR's
mmio page which may
On 04/27/2016 10:43 PM, Yongji Xie wrote:
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c
On 05/06/2016 01:05 AM, Alex Williamson wrote:
On Thu, 5 May 2016 12:15:46 +
"Tian, Kevin" wrote:
From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
Sent: Thursday, May 05, 2016 7:43 PM
Hi David and Kevin,
On 2016/5/5 17:54, David Laight wrote:
From: Tian, Kevin
Sent: 05 May 2016 10:
and one of the approaches uses this helper, another one
(proposed by David a couple of months ago) does not. This week I'll post a
version and see if it goes well, then we will ditch iommu_group_get_by_id().
>
> commit aa16bea929aed6ea854b55d2be8306a9fb40e694
> Author: Alexey Kardashevskiy
> Date:
risc-linux"
Please comment. Thanks.
Changelog:
v5:
* redid the whole thing via so-called IOMMU group capabilities
v4:
* rebased on recent upstream
* got all 6 patches from v2 (v3 was missing some)
Alexey Kardashevskiy (5):
iommu: Add capabilities to a group
iommu: Set IOMMU_GROUP_CAP_IS
userspace. Various architectures will enable it
when they decide that it is safe to do so.
Signed-off-by: Alexey Kardashevskiy
---
include/linux/iommu.h | 20
drivers/iommu/iommu.c | 28
2 files changed, 48 insertions(+)
diff --git a/include/linux
/documents/product-specifications/vt-directed-io-spec.pdf
[2] "2.2 Data Structures" and "2.2.5 Interrupt Remapping Tables"
https://support.amd.com/TechDocs/48882_IOMMU.pdf
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/amd_iommu.c | 3 +++
drivers/iommu/intel-iommu
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if MSI remapping is
enabled on an IRQ domain; this is expected to set the capability
on ARM.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers
upt Vector Table (IVT) to identify the interrupt server.
Without these translations in place, MSIX messages won't pass PHB.
[1] 3.2.4. MSI Design
http://openpowerfoundation.org/wp-content/uploads/resources/IODA2Spec/IODA2WGSpec-1.0.0-20160217.pdf
Signed-off-by: Alexey Kardashevskiy
---
arch
harm to other devices
or cause spurious interrupts visible to the kernel.
This adds a wrapping helper to check if a capability is supported by
an IOMMU group.
Signed-off-by: Alexey Kardashevskiy
---
include/linux/vfio.h | 1 +
drivers/vfio/pci/vfio_pci.c
Folks,
Is there anything to change besides those compiler errors and David's
comment in 5/5? Or the while patchset is too bad? Thanks.
On 07/08/17 17:25, Alexey Kardashevskiy wrote:
> This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for
> mmapping MSI
Folks,
Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I
repost this or go back to PCI bus flags or something else? Thanks.
On 14/08/17 19:45, Alexey Kardashevskiy wrote:
> Folks,
>
> Is there anything to change besides those compiler errors and David's
&g
On 21/08/17 12:47, Alexey Kardashevskiy wrote:
> Folks,
>
> Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I
> repost this or go back to PCI bus flags or something else? Thanks.
Anyone, any help? How do we proceed with this? Thanks.
>
>
>
> O
On 29/08/17 12:58, Alexey Kardashevskiy wrote:
> On 21/08/17 12:47, Alexey Kardashevskiy wrote:
>> Folks,
>>
>> Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I
>> repost this or go back to PCI bus flags or something else? Thanks.
>
>
>
On 17/11/17 11:13, Alex Williamson wrote:
> On Tue, 14 Nov 2017 10:47:12 +1100
> Alexey Kardashevskiy wrote:
>
>> On 27/10/17 14:00, Alexey Kardashevskiy wrote:
>>> This adds trace_map/trace_unmap tracepoints to spapr driver. Type1 already
>>> uses t
On 17/11/17 17:58, Alexey Kardashevskiy wrote:
> On 17/11/17 11:13, Alex Williamson wrote:
>> On Tue, 14 Nov 2017 10:47:12 +1100
>> Alexey Kardashevskiy wrote:
>>
>>> On 27/10/17 14:00, Alexey Kardashevskiy wrote:
>>>> This adds trace_map/trace_unmap
On 25/04/2019 05:14, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
> 1 file changed, 6 insertio
On 03/06/2020 14:13, Alexey Kardashevskiy wrote:
>
>
> On 09/05/2020 18:19, Christoph Hellwig wrote:
>> On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 17/04/2020 17:58, Christoph Hellwig wrote:
>>>
On 09/07/2020 01:24, Christoph Hellwig wrote:
> Several IOMMU drivers have a bypass mode where they can use a direct
> mapping if the devices DMA mask is large enough. Add generic support
> to the core dma-mapping code to do that to switch those drivers to
> a common solution.
>
> Signed-off-b
On 14/07/2020 17:07, Christoph Hellwig wrote:
> On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/07/2020 01:24, Christoph Hellwig wrote:
>>> Several IOMMU drivers have a bypass mode where they can use a direct
>>> m
On 31/08/2020 16:40, Christoph Hellwig wrote:
On Sun, Aug 30, 2020 at 11:04:21AM +0200, Cédric Le Goater wrote:
Hello,
On 7/8/20 5:24 PM, Christoph Hellwig wrote:
Use the DMA API bypass mechanism for direct window mappings. This uses
common code and speed up the direct mapping case by avoid
On 4/29/22 00:53, David Gibson wrote:
On Thu, Mar 24, 2022 at 04:04:03PM -0600, Alex Williamson wrote:
On Wed, 23 Mar 2022 21:33:42 -0300
Jason Gunthorpe wrote:
On Wed, Mar 23, 2022 at 04:51:25PM -0600, Alex Williamson wrote:
My overall question here would be whether we can actually achi
On 5/24/22 23:25, Jason Gunthorpe wrote:
On Mon, May 23, 2022 at 04:02:22PM +1000, Alexey Kardashevskiy wrote:
Which means the guest RAM does not need to be all mapped in that base IOAS
suggested down this thread as that would mean all memory is pinned and
powervm won't be able to sw
On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
IOMMU_CACHE means that normal DMAs do not require any additional coherency
mechanism and is the basic uAPI that VFIO exposes to userspace. For
instance VFIO applications like DPDK will not work if additional coherency
operations are required.
On 7/1/22 16:07, Tian, Kevin wrote:
From: Alexey Kardashevskiy
Sent: Friday, July 1, 2022 12:58 PM
On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
IOMMU_CACHE means that normal DMAs do not require any additional
coherency
mechanism and is the basic uAPI that VFIO exposes to userspace
On 05/05/2021 04:15, Jason Gunthorpe wrote:
On Tue, May 04, 2021 at 01:54:55PM +1000, David Gibson wrote:
On Mon, May 03, 2021 at 01:05:30PM -0300, Jason Gunthorpe wrote:
On Thu, Apr 29, 2021 at 01:20:22PM +1000, David Gibson wrote:
There is a certain appeal to having some
'PPC_TCE_CREATE_S
On 30/09/2020 18:55, Christoph Hellwig wrote:
Most of the dma_direct symbols should only be used by direct.c and
mapping.c, so move them to kernel/dma. In fact more of dma-direct.h
should eventually move, but that will require more coordination with
other subsystems.
Because of this change,
ifdef".
Please comment. Thanks.
Alexey Kardashevskiy (2):
dma: Allow mixing bypass and normal IOMMU operation
powerpc/dma: Fallback to dma_ops when persistent memory present
arch/powerpc/kernel/dma-iommu.c| 12 -
arch/powerpc/platforms/pseries/iommu.c | 44 ++---
where bypass
can still work and we invoke direct DMA API; when DMA handle is outside
that limit, we fall back to DMA ops.
This adds a CONFIG_DMA_OPS_BYPASS_BUS_LIMIT config option which is off
by default and will be enable for PPC_PSERIES in the following patch.
Signed-off-by: Alexey Kardashevskiy
DMA ops.
This should not change the existing behaviour when no persistent memory
as dev->dma_ops_bypass is expected to be set.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/dma-iommu.c| 12 +--
arch/powerpc/platforms/pseries/iommu.c | 44 ---
ng only for RAM and
sets the dev->bus_dma_limit to let the generic code decide whether to
call into the direct DMA or the indirect DMA ops.
This should not change the existing behaviour when no persistent memory
as dev->dma_ops_bypass is expected to be set.
Signed-off-by: Alexey Kardashevskiy
emove incorrect sparse #ifdef".
Please comment. Thanks.
Alexey Kardashevskiy (2):
dma: Allow mixing bypass and mapped DMA operation
powerpc/dma: Fallback to dma_ops when persistent memory present
arch/powerpc/kernel/dma-iommu.c| 70 +-
arch/powerpc/platfor
still work and
we invoke direct DMA API. The following patch checks the bus limit
on POWERPC to allow or disallow direct mapping.
This adds a CONFIG_ARCH_HAS_DMA_SET_MASK config option to make arch_
hooks no-op by default.
Signed-off-by: Alexey Kardashevskiy
---
kernel/dma/mapping.c | 24
On 28/10/2020 03:48, Christoph Hellwig wrote:
+static inline bool dma_handle_direct(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle >= dev->archdata.dma_offset;
+}
This won't compile except for powerpc, and directly accesing arch members
in common code is a bad idea.
On 29/10/2020 04:22, Christoph Hellwig wrote:
On Wed, Oct 28, 2020 at 06:00:29PM +1100, Alexey Kardashevskiy wrote:
At the moment we allow bypassing DMA ops only when we can do this for
the entire RAM. However there are configs with mixed type memory
where we could still allow bypassing
On 29/10/2020 04:21, Christoph Hellwig wrote:
On Wed, Oct 28, 2020 at 05:55:23PM +1100, Alexey Kardashevskiy wrote:
It is passing an address of the end of the mapped area so passing a page
struct means passing page and offset which is an extra parameter and we do
not want to do anything
On 29/10/2020 11:40, Michael Ellerman wrote:
Alexey Kardashevskiy writes:
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index e4198700ed1a..91112e748491 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries
still work and
we invoke direct DMA API. The following patch checks the bus limit
on POWERPC to allow or disallow direct mapping.
This adds a CONFIG_ARCH_HAS_DMA_SET_MASK config option to make arch_
hooks no-op by default.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* wrapped long lines
ng only for RAM and
sets the dev->bus_dma_limit to let the generic code decide whether to
call into the direct DMA or the indirect DMA ops.
This should not change the existing behaviour when no persistent memory
as dev->dma_ops_bypass is expected to be set.
Signed-off-by: Alexey Kardashevskiy
4525c8781ec0 Linus Torvalds "scsi: qla2xxx: remove incorrect sparse #ifdef".
Please comment. Thanks.
Alexey Kardashevskiy (2):
dma: Allow mixing bypass and mapped DMA operation
powerpc/dma: Fallback to dma_ops when persistent memory present
arch/powerpc/kernel/dma-iommu.c
("powerpc: use the generic dma_ops_bypass mode")
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/dma-iommu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 111249fd619d..d646077bcbcf 100644
--- a/a
-...@ozlabs.ru/
Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
Signed-off-by: Alexey Kardashevskiy
---
I have not looked into the domains for ages, what is missing here? With thi
On 28/04/2022 23:18, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary. This also
leaves the custom initcall effectively doing nothing but register
the driver, which no longer needs to happen early either, so convert
it to builtin_platform_driver().
Signed-off-by: Ro
72 matches
Mail list logo
