On 10/11/17 22:18, Jacob Pan wrote:
> On Fri, 10 Nov 2017 13:54:59 +
> Jean-Philippe Brucker wrote:
>
>> On 09/11/17 19:36, Jacob Pan wrote:
>>> On Tue, 7 Nov 2017 11:38:50 +
>>> Jean-Philippe Brucker wrote:
>>>
>>>> I think the
On 11/11/17 00:00, Jacob Pan wrote:
> On Fri, 10 Nov 2017 13:54:59 +
> Jean-Philippe Brucker wrote:
>
>> /*
>> * Note: I tried to synthesize what I believe would be useful to
>> device
>> * drivers and guests, with regards to the kind of faults that
On 13/11/17 16:57, Jacob Pan wrote:
> On Mon, 13 Nov 2017 13:06:24 +
> Jean-Philippe Brucker wrote:
>
>> On 10/11/17 22:18, Jacob Pan wrote:
>>> On Fri, 10 Nov 2017 13:54:59 +
>>> Jean-Philippe Brucker wrote:
>>>
>>>> On 09/11/17
Hi Yi,
Sorry for the late reply, I seem to have missed this.
On 20/10/17 11:07, Liu, Yi L wrote:
[...]
>>> +
>>> +/* Generic fault types, can be expanded IRQ remapping fault */ enum
>>> +iommu_fault_type {
>>> + IOMMU_FAULT_DMA_UNRECOV = 1,/* unrecoverable fault */
>>> + IOMMU_FAULT_PAGE
vGIC driver
will need to split their values into two 32bit registers: LRn and LRCn.
Signed-off-by: Jean-Philippe Brucker
---
arch/arm64/include/asm/arch_gicv3.h | 35 ---
drivers/irqchip/irq-gic-v3.c| 25 -
include/linux/irqchip
- fix the mistakes pointed out on the list,
- add a patch to select ARM_GIC_V3 under ARCH_VIRT.
Cheers,
Jean
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310124.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/327034.html
Jean-Philippe Bruck
This patch moves the GICv3 system register access helpers to
arch/arm64/. Their 32bit counterparts will need to use mrc/mcr accesses
instead of mrs_s/msr_s.
Signed-off-by: Jean-Philippe Brucker
---
arch/arm64/include/asm/arch_gicv3.h | 140 +++
drivers/irqchip
ro on 32bit
architectures.
Signed-off-by: Jean-Philippe Brucker
---
arch/arm/include/asm/arch_gicv3.h | 188 +
1 file changed, 188 insertions(+)
create mode 100644 arch/arm/include/asm/arch_gicv3.h
diff --git a/arch/arm/include/asm/arch_gicv3.h
b/arc
patch specializes the IROUTER and TYPER accesses.
Since the latter is an ID register, it won't need to be read atomically,
but we still avoid future confusion by using gic_read_typer instead of a
generic gic_readq.
Signed-off-by: Jean-Philippe Brucker
---
arch/arm64/include/asm/arch_gicv3.h |
This patch allows ARM guests to use GICv3 on an arm64 host
Signed-off-by: Jean-Philippe Brucker
---
arch/arm/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..0d72535 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -819,6
is
only enabled on the 64bit side. The selection is done unconditionally
because CONFIG_ARM_GIC_V3 is always enabled on arm64.
Signed-off-by: Jean-Philippe Brucker
---
arch/arm64/kvm/Kconfig |4
include/kvm/arm_vgic.h |4 ++--
virt/kvm/arm/vgic.c|4 ++--
3 files changed, 8
upport for private PASIDs
Provide an API for allocating PASIDs and populating them manually. To ease
cleanup and factor allocation code, reuse the io_mm structure for private
PASID. Private io_mm has a NULL mm_struct pointer, and cannot be bound to
multiple devices. The mm_alloc(
On 12/01/18 10:21, Peter Maydell wrote:
> On 10 January 2018 at 11:25, Jean-Philippe Brucker
> wrote:
>> Hi Peter,
>>
>> On 10/01/18 11:19, Peter Maydell wrote:
>>> Are there uses that make it worthwhile to get virtio-1
>>> support added to virtio-mmio, r
Hi Jacob,
I've got minor comments after working with this patch, sorry for the
multiple replies
On 17/11/17 18:55, Jacob Pan wrote:
[...]
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 829e9e9..97b7990 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -
Hi Peter,
On 10/01/18 11:19, Peter Maydell wrote:
> On 10 January 2018 at 11:06, Michael S. Tsirkin wrote:
>> For virtio-mmio? I don't seem to see that code in
>> hw/virtio/virtio-mmio.c
>> For example I still see handling for VIRTIO_MMIO_QUEUE_PFN
>> there, and no handling for VIRTIO_MMIO_QUEUE_
Hi Jacob,
On 17/11/17 18:55, Jacob Pan wrote:
[...]
> +/**
> + * struct iommu_fault_event - Generic per device fault data
> + *
> + * - PCI and non-PCI devices
> + * - Recoverable faults (e.g. page request), information based on PCI ATS
> + * and PASID spec.
> + * - Un-recoverable faults of device
On 28/12/17 19:25, Jacob Pan wrote:
[...]
>>> + * @size: 2^size of 4K pages, 0 for 4k, 9 for 2MB,
>>> etc.
>>
>> Having only power of two invalidation seems too restrictive for a
>> software interface. You might have the same problem as above, where
>> the guest or userspace needs to sen
On 17/11/17 18:55, Jacob Pan wrote:
[...]
> +static inline int iommu_register_device_fault_handler(struct device *dev,
> + iommu_dev_fault_handler_t
> handler,
> + void *data)
> +{
> + return 0;> +}
> +
> +
Hi Valmiki,
On 12/05/18 13:55, valmiki wrote:
> Hi All,
>
> What is the difference between IOVA address and bus address
> when SMMU is enabled ?
They are the same. You'll use one term or the other depending on what
system component you're talking about. "IOVA" only means something when
talking a
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> btw this discussion was raised when discussing the I/O page fault handling
> process. Currently the IOMMU layer implements a per-device fault reporting
> mechanism, which requires VFIO to register a handler to receive all faults
> on i
On Wed, Apr 07, 2021 at 04:36:54PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
>
> > * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> > No operation available since we don't know wh
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> If the guest wants to use a larger physical address space place
> the RAM at upper half of the address space. Otherwise, it uses the
> default layout.
>
> Signed-off-by: Suzuki K Poulose
> ---
> arm/aarch32/include/kvm/kvm-arch.h | 1 +
>
On 23/04/18 21:43, Jacob Pan wrote:
[...]
>> The last name is a bit unfortunate. Since the Arm architecture uses
>> the name "context" for what a PASID points to, "Device cache" would
>> suit us better but it's not important.
>>
> or call it device context cache. actually so far context cache is he
On 25/04/18 16:37, Jacob Pan wrote:
>> In the other cases (unsupported PRI or rogue guest) then disabling PRI
>> using a FAILURE status might be the right thing to do. However,
>> assuming the device follows the PCI spec it will stop sending page
>> requests once there are as many PPRs in flight as
Hi,
I noticed a couple issues when testing
On 16/04/18 22:49, Jacob Pan wrote:
> +int iommu_register_device_fault_handler(struct device *dev,
> + iommu_dev_fault_handler_t handler,
> + void *data)
> +{
> + struct iommu_pa
On 01/05/18 23:58, Jacob Pan wrote:
Maybe this should be called "NG_PAGE_PASID",
>>> Sure. I was thinking page range already implies non-global pages.
and "DOMAIN_PAGE" should
instead be "PAGE_PASID". If I understood their meaning correctly,
it would be more consistent with
On 27/02/2019 21:41, Jacob Pan wrote:
> On Tue, 26 Feb 2019 12:17:43 +0100
> Joerg Roedel wrote:
>
>> Hi Jean-Philippe,
>>
>> Thanks for the patch! I think this is getting close to be applied
>> after the next merge window.
>>
>> On Wed, Feb 20, 20
Hi Leizhen,
On 01/03/2019 04:44, Leizhen (ThunderTown) wrote:
>
>
> On 2019/2/26 20:36, Hanjun Guo wrote:
>> Hi Jean,
>>
>> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
>>> Hi,
>>>
>>> On 31/01/2019 13:52, Zhen Lei wrote:
>>>&g
Hi Eric,
On 25/01/2019 16:49, Auger Eric wrote:
[...]
>>> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
>>> index 7a7cf7a3de7c..4605f5cfac84 100644
>>> --- a/include/uapi/linux/iommu.h
>>> +++ b/include/uapi/linux/iommu.h
>>> @@ -47,4 +47,99 @@ struct iommu_pasid_table_confi
On 26/02/2019 11:17, Joerg Roedel wrote:
> Hi Jean-Philippe,
>
> Thanks for the patch! I think this is getting close to be applied after
> the next merge window.
>
> On Wed, Feb 20, 2019 at 02:27:59PM +0000, Jean-Philippe Brucker wrote:
>> +int iommu_sva_bind_device(st
On 27/02/2019 04:25, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vhost tree got conflicts in:
>
> drivers/iommu/Kconfig
> drivers/iommu/Makefile
>
> between commit:
>
> 004240dcc222 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
>
> from the iommu tree and com
Hi Fenghua,
[Trimmed the Cc list]
On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote:
> When a new mm is created, its PASID should be cleared, i.e. the PASID is
> initialized to its init state 0 on both ARM and X86.
I just noticed this patch was dropped in v7, and am wondering whether we
On Mon, Feb 01, 2021 at 08:26:41PM +0800, Keqian Zhu wrote:
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > + struct arm_smmu_master *master)
> > +{
> > + int i;
> > + int ret = 0;
> > + struct arm_smmu_stream *new_stream, *cur_stream;
> >
Hi Keqian,
On Fri, Feb 05, 2021 at 05:13:50PM +0800, Keqian Zhu wrote:
> > We need to accommodate the firmware override as well if we need this to be
> > meaningful. Jean-Philippe is already carrying a suitable patch in the SVA
> > stack[1].
> Robin, Thanks for pointing it out.
>
> Jean, I see
Hi,
On Thu, Feb 04, 2021 at 06:52:10AM +, Tian, Kevin wrote:
> > >>> The static pinning and mapping problem in VFIO and possible solutions
> > >>> have been discussed a lot [1, 2]. One of the solutions is to add I/O
> > >>> page fault support for VFIO devices. Different from those relatively
>
On Thu, Jul 30, 2020 at 08:28:56AM -0400, Qian Cai wrote:
> On Tue, Jul 28, 2020 at 05:21:26PM +0200, Jean-Philippe Brucker wrote:
> > When a tracing BPF program attempts to read memory without using the
> > bpf_probe_read() helper, the verifier marks the load instructi
On Thu, Jul 30, 2020 at 09:47:39PM +0200, Daniel Borkmann wrote:
> On 7/30/20 4:22 PM, Jean-Philippe Brucker wrote:
> > On Thu, Jul 30, 2020 at 08:28:56AM -0400, Qian Cai wrote:
> > > On Tue, Jul 28, 2020 at 05:21:26PM +0200, Jean-Philippe Brucker wrote:
> > > > When
On Wed, Jan 13, 2021 at 08:05:11PM +0800, Zhangfei Gao wrote:
> > > + /* Device-tree can set the stall property */
> > > + if (!pdev->dev.of_node &&
> > > + device_add_properties(&pdev->dev, properties))
> > Does this mean "dma-can-stall" *can* be set via DT, and if it is, this
> > quirk is not
On Wed, Jan 13, 2021 at 10:21:31AM +, Qais Yousef wrote:
> On 01/12/21 12:07, Andrii Nakryiko wrote:
> > > > > $ sudo ./test_progs -v -t module_attach
> > > >
> > > > use -vv when debugging stuff like that with test_progs, it will output
> > > > libbpf detailed logs, that often are very
On Mon, Jan 18, 2021 at 10:55:52AM +, John Garry wrote:
> On 18/01/2021 10:08, Jean-Philippe Brucker wrote:
> > > > Any idea why that's happening? This fix seems ok but if we're expecting
> > > > allocation failures for the loaded magazine then we could
Hi Eric,
On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote:
> >> The uacce-devel branches from
> >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment
> >>> (they track the latest sva/zip-devel branch
> >>> https://jpbrucker.net/git/linux/ which is roughly based o
On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > > > Also wondering about device driver allocating auxiliary domains for
> > > > their private
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > And a flag IOMMU_SVA_BIND_SUPERVISOR (not that I plan to implement it in
> > the SMMU, but I think we need to clean the current usage)
> >
> You mean move #define SVM_FLAG_SUPERVISOR_MODE out of Intel code to be a
> generic flag in iom
Hi Jacob,
On Thu, Mar 18, 2021 at 05:22:34PM -0700, Jacob Pan wrote:
> Hi Jean,
>
> Slightly off the title. As we are moving to use cgroup to limit PASID
> allocations, it would be much simpler if we enforce on the current task.
Yes I think we should do that. Is there a problem with charging the
On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
>
> > Although there is no use for it at the moment (only two upstream users and
> > it looks like amdkfd always uses current too), I quite l
On Thu, Mar 04, 2021 at 09:46:03AM -0800, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Thu, 4 Mar 2021 10:49:37 +0100, Jean-Philippe Brucker
> wrote:
>
> > On Wed, Mar 03, 2021 at 04:02:05PM -0800, Jacob Pan wrote:
> > > Hi Jacob,
> > >
> > &
Hi,
On Tue, Feb 23, 2021 at 10:06:15PM +0100, Eric Auger wrote:
> This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
> to (un)register the guest MSI binding to the host. This latter
> then can use those stage 1 bindings to build a nested stage
> binding targeting the physical MSIs.
No
On Fri, Mar 05, 2021 at 09:30:49AM +0100, Jean-Philippe Brucker wrote:
> That works but isn't perfect, because the hardware resource of shared
> address spaces can be much lower that PID limit - 16k ASIDs on Arm. To
Sorry I meant 16-bit here - 64k
Thanks,
Jean
On Tue, Mar 30, 2021 at 10:07:55AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
>
> > It's not inconceivable to have a control queue doing DMA tagged with
> > PASID. The devices I know either use untagged DMA, or hav
On Fri, Jan 15, 2021 at 05:43:31PM +0530, Vivek Gautam wrote:
> Update base address information in vendor pasid table info to pass that
> to user-space for stage1 table management.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
;t too invasive. Even if we called directly
into the SMMU driver from the virtio one, we'd still need patch 3 and
separate TLB invalidations ops.
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc:
On Fri, Jan 15, 2021 at 05:43:35PM +0530, Vivek Gautam wrote:
> aisd_bits data is required to prepare stage-1 tables for arm-smmu-v3.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc: Eric Auge
On Fri, Jan 15, 2021 at 05:43:33PM +0530, Vivek Gautam wrote:
> From: Jean-Philippe Brucker
>
> Add required UAPI defines for probing table format for underlying
> iommu hardware. The device may provide information about hardware
> tables and additional capabilities for each
On Fri, Jan 15, 2021 at 05:43:32PM +0530, Vivek Gautam wrote:
> Te change allows different consumers of arm-smmu-v3-cd-lib to set
> their respective sync op for pasid entries.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> C
On Fri, Jan 15, 2021 at 05:43:36PM +0530, Vivek Gautam wrote:
> Add info about asid_bits and additional flags to table format
> probing header.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Michael S. Tsirkin
> Cc: Robin Murphy
> Cc:
gned-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Michael S. Tsirkin
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc: Eric Auger
> Cc: Alex Williamson
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Liu Yi L
> Cc: Lorenzo Pieralisi
> Cc: Sh
On Fri, Jan 15, 2021 at 05:43:40PM +0530, Vivek Gautam wrote:
[...]
> +static int viommu_setup_pgtable(struct viommu_endpoint *vdev,
> + struct viommu_domain *vdomain)
> +{
> + int ret, id;
> + u32 asid;
> + enum io_pgtable_fmt fmt;
> + struct io_pgtable_
On Wed, Mar 03, 2021 at 04:02:05PM -0800, Jacob Pan wrote:
> Hi Jacob,
>
> On Wed, 3 Mar 2021 13:17:26 -0800, Jacob Pan
> wrote:
>
> > Hi Tejun,
> >
> > On Wed, 3 Mar 2021 10:44:28 -0500, Tejun Heo wrote:
> >
> > > On Sat, Feb 27, 2021 at 02:01:23PM -0800, Jacob Pan wrote:
> > > > IOASIDs a
On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gu
On Fri, Mar 12, 2021 at 06:59:17PM +0530, Vivek Kumar Gautam wrote:
> > > + /* XXX HACK: set feature bit ARM_SMMU_FEAT_2_LVL_CDTAB */
> > > + pst_cfg->vendor.cfg.feat_flag |= (1 << 1);
> >
> > Oh right, this flag is missing. I'll add
> >
> >#define VIRTIO_IOMMU_PST_ARM_SMMU3_F_CD2L (1ULL << 1
On Fri, Mar 12, 2021 at 06:39:05PM +0530, Vivek Kumar Gautam wrote:
> To complete the page request we would also need to send the response back to
> the host from virtio backend when handling page request. So the virtio
> command should also be accompanied with a vfio api to send the page request
>
On Fri, Mar 12, 2021 at 06:17:55PM +0530, Vivek Kumar Gautam wrote:
> > Regarding the overall design, I was initially assigning page directories
> > instead of whole PASID tables, which would simplify the driver and host
> > implementation. A major complication, however, is SMMUv3 accesses PASID
>
On Thu, Mar 25, 2021 at 02:16:45PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> > wrote:
> >
> > > On Wed, Mar 24,
eardown_dma_ops() on x86 to clear the device's dma_ops
pointer during driver unbind.
Fixes: 08a27c1c3ecf ("iommu: Add support to change default domain of an iommu
group")
Signed-off-by: Jean-Philippe Brucker
---
arch/x86/Kconfig | 1 +
arch/x86/kernel/pci-dma.c | 7 +
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > table
> > happens within guest. They only need to bind the guest PASID table to
> > host.
In this case each VM has its own IOASID space, and the host IOASID
On Sat, Apr 17, 2021 at 02:06:44PM +0200, Borislav Petkov wrote:
> Nope, sorry, no joy. Zapping it from tip.
>
> With that patch, it fails booting on my test box with messages like
> (typing up from video I took):
>
> ...
> ata: softreset failed (1st FIS failed)
> ahci :03:00:1: AMD-Vi: Event
On Thu, Apr 08, 2021 at 10:08:56AM -0700, Jacob Pan wrote:
> diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c
> index bd41405..bd99f6b 100644
> --- a/drivers/iommu/iommu-sva-lib.c
> +++ b/drivers/iommu/iommu-sva-lib.c
> @@ -12,27 +12,33 @@ static DECLARE_IOASID_SET(iommu_s
gt; Link: https://lore.kernel.org/linux-iommu/YFhiMLR35WWMW%2FHu@myrica/
> Suggested-by: Jean-Philippe Brucker
> Signed-off-by: Jacob Pan
> ---
> drivers/dma/idxd/cdev.c | 2 +-
> drivers/dma/idxd/init.c | 6 +++---
> drivers/iommu
Hi Shameer,
On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote:
> Hi Jean/zhangfei,
> Is it possible to have a branch with minimum required SVA/UACCE related
> patches
> that are already public and can be a "stable" candidate for future respin of
> Eric's series?
> Please
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
> From: Jean-Philippe Brucker
>
> [ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
>
> The test fails because of a recent fix to the verifier, even though this
That fix is commit b02709587ea3 ("
From: Fenghua Yu
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Reviewed-by: Tony Luck
Signed-off-by: Fenghua Yu
Signed-off-by: Jean-Philippe Brucker
---
This patch was part of the series introducing mm->pa
On Mon, Mar 01, 2021 at 03:00:11PM -0800, Jacob Pan wrote:
> > functionality is not a problem without this patch on x86. But I think
> I feel the reason that x86 doesn't care is that mm->pasid is not used
> unless bind_mm is called.
I think vt-d also maintains the global_svm_list, that tells wheth
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > I think the proper fix would be to not rely on custom hooks into a
> > particular
> > IOMMU driver, but to instead ensure that the amdgpu driver can do everything
> > it needs through the regular linux/iommu.h interface
>
> Signed-off-by: John Garry
> Tested-by: Xiang Chen
> Reviewed-by: Zhen Lei
Reviewed-by: Jean-Philippe Brucker
(unless we find a better solution for patch 3)
> ---
> drivers/iommu/iova.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> d
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> A similar crash to the following could be observed if initial CPU rcache
> magazine allocations fail in init_iova_rcaches():
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded mag
On Thu, Dec 10, 2020 at 02:23:09AM +0800, John Garry wrote:
> Leizhen reported some time ago that IOVA performance may degrade over time
> [0], but unfortunately his solution to fix this problem was not given
> attention.
>
> To summarize, the issue is that as time goes by, the CPU rcache and depo
On Mon, Jan 18, 2021 at 09:24:17AM +, John Garry wrote:
> On 15/01/2021 17:30, Jean-Philippe Brucker wrote:
> > On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> > > A similar crash to the following could be observed if initial CPU rcache
> > > m
oes not support
> `ubfx r7,r7,#28,#4' in ARM mode
> arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support
> `isb' in ARM mode
>
> Signed-off-by: Vincent Stehlé
> Cc: Jean-Philippe Brucker
> Cc: Marc Zyngier
> Cc: Russell King
> -
Hi Eric,
On Tue, Mar 01, 2016 at 06:27:46PM +, Eric Auger wrote:
>[...]
> +
> +int iommu_get_single_reserved(struct iommu_domain *domain,
> + phys_addr_t addr, int prot,
> + dma_addr_t *iova)
> +{
> + unsigned long order = __ffs(domain->o
Hi Eric,
On Thu, Apr 07, 2016 at 11:33:42AM +0200, Eric Auger wrote:
> Alex,
> On 04/07/2016 01:12 AM, Alex Williamson wrote:
> > On Mon, 4 Apr 2016 08:07:01 +
> > Eric Auger wrote:
> >
> >> This patch introduces iommu_get/put_single_reserved.
> >>
> >> iommu_get_single_reserved allows to a
On 17/03/2019 16:43, Auger Eric wrote:
>>> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
>>> index 532a64075f23..e4c6a447e85a 100644
>>> --- a/include/uapi/linux/iommu.h
>>> +++ b/include/uapi/linux/iommu.h
>>> @@ -159,4 +159,75 @@ struct iommu_pasid_table_config {
>>> };
Hi Jacob,
There seem to be a mix-up here, the changes from your v2 are lost and
patches 1 and 3 are back to v1. Assuming this isn't intended, I'll
review v2 of this patch since it looked good to me overall.
Thanks,
Jean
On Mon, Jul 08, 2019 at 09:58:16AM +0200, Auger Eric wrote:
> > + ret = pci_enable_pasid(pdev, features);
> > + if (!ret)
> > + master->ssid_bits = min_t(u8, ilog2(num_pasids),
> > + master->smmu->ssid_bits);
> I don't really get why this setting is
On Wed, Sep 18, 2019 at 04:26:32PM -0700, Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space ID)
> allows to share process address spaces wi
success.
>>
>> * iommu_pasid_free(pasid, ioasid)
>> - Free a PASID to the pool so that it could be consumed by
>> others.
>>
>> This also adds below helpers to lookup or iterate PASID items
>> associated with a consumer.
>>
>> * iommu_pasid_for
The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.
---
Jean-Philippe Brucker (1):
iommu: Bind process address spaces to devices
drivers/iommu/iommu.c | 104 ++
include/linux/iommu.h | 24 ++
2 files changed, 128 insertions(+)
--
2.20.1
driver should disable DMA from the given
context, so that the core IOMMU can reallocate the PASID.
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu.c | 104
On 21/01/2019 11:51, Pierre Morel wrote:
> On 18/01/2019 14:51, Jean-Philippe Brucker wrote:
>> Hi Pierre,
>>
>> On 18/01/2019 13:29, Pierre Morel wrote:
>>> On 17/01/2019 14:02, Robin Murphy wrote:
>>>> On 15/01/2019 17:37, Pierre Morel wrote:
>>&g
Hi Peter,
On 30/01/2019 05:57, Peter Xu wrote:
> AMD IOMMU driver is using the clear_flush_young() to do cache flushing
> but that's actually already covered by invalidate_range(). Remove the
> extra notifier and the chunks.
Aren't uses of clear_flush_young() and invalidate_range() orthogonal? I
On 15/01/2019 21:06, Auger Eric wrote:
>>> + iommu_report_device_fault(master->dev, &event);
>>
>> We should return here if the fault is successfully injected
>
> Even if the fault gets injected in the guest can't it be still useful to
> get the message below on host side?
I don't think
On 14/01/2019 22:32, Jacob Pan wrote:
>> [...]
+/**
+ * struct iommu_fault - Generic fault data
+ *
+ * @type contains fault type
+ * @reason fault reasons if relevant outside IOMMU driver.
+ * IOMMU driver internal faults are not reported.
+ * @addr: tells the of
On 15/01/2019 21:27, Auger Eric wrote:
[...]
/* iommu fault flags */
-#define IOMMU_FAULT_READ 0x0
-#define IOMMU_FAULT_WRITE 0x1
+#define IOMMU_FAULT_READ (1 << 0)
+#define IOMMU_FAULT_WRITE (1 << 1)
+#define IOMMU_FAULT_EXEC (1 << 2)
Hi Pierre,
On 18/01/2019 13:29, Pierre Morel wrote:
> On 17/01/2019 14:02, Robin Murphy wrote:
>> On 15/01/2019 17:37, Pierre Morel wrote:
>>> The s390 iommu can only allow DMA transactions between the zPCI device
>>> entries start_dma and end_dma.
>>>
>>> Let's declare the regions before start_dm
On 01/02/2019 03:51, Peter Xu wrote:
> On Thu, Jan 31, 2019 at 12:25:40PM +0000, Jean-Philippe Brucker wrote:
>> On 31/01/2019 07:59, Peter Xu wrote:
>>> On Wed, Jan 30, 2019 at 12:27:40PM +0000, Jean-Philippe Brucker wrote:
>>>> Hi Peter,
>>>
>>> Hi
On 25/01/2019 08:55, Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 1/25/19 9:39 AM, Auger Eric wrote:
>> Hi Jean-Philippe,
>>
>> On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote:
>>> On 08/01/2019 10:26, Eric Auger wrote:
>>>> From: Jacob Pan
>&
On 20/05/2019 20:22, Jacob Pan wrote:
> On Thu, 16 May 2019 09:14:29 -0700
> Jacob Pan wrote:
>
>> On Thu, 16 May 2019 15:14:40 +0100
>> Jean-Philippe Brucker wrote:
>>
>>> Hi Jacob,
>>>
>>> On 03/05/2019 23:32, Jacob Pan wrote:
>>
care about non internal faults that are likely to be reported
to an external subsystem.
Signed-off-by: Jacob Pan
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Liu, Yi L
Signed-off-by: Ashok Raj
Signed-off-by: Eric Auger
---
include/linux/iommu.h | 43 ++
include/uapi
OS.
Once handled, the fault must be completed by sending a page response back
to the IOMMU. Add an iommu_page_response() function to complete a page
fault.
Signed-off-by: Jacob Pan
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu.c | 95
Hi Eric,
On 13/05/2019 10:14, Auger Eric wrote:
> I noticed my qemu integration was currently incorrectly using PASID
> invalidation for ASID based invalidation (SMMUV3 Stage1 CMD_TLBI_NH_ASID
> invalidation command). So I think we also need ARCHID invalidation.
> Sorry for the late notice.
>>
>
On 12/05/2019 18:16, Michael S. Tsirkin wrote:
> On Thu, Feb 28, 2019 at 11:04:42AM +0100, Joerg Roedel wrote:
>> On Wed, Feb 27, 2019 at 08:58:36AM -0500, Michael S. Tsirkin wrote:
>>> Even though it's not going into 5.1 I feel it's helpful to keep it in
>>> the vhost tree until the next cycle, it
1 - 100 of 230 matches
Mail list logo
