Re: [PATCH 6/8] iommu/arm-smmu-v3: Support auxiliary domains

On 26/06/2019 18:59, Will Deacon wrote: >> +static void arm_smmu_aux_detach_dev(struct iommu_domain *domain, struct >> device *dev) >> +{ >> +struct iommu_domain *parent_domain; >> +struct arm_smmu_domain *parent_smmu_domain; >> +struct arm_smmu_master *master = dev_to_master(dev); >>

Re: linux-next: manual merge of the char-misc tree with the driver-core tree

Hi, [Adding Joerg] On Mon, Jul 01, 2019 at 09:04:18PM +0100, Nathan Chancellor wrote: > On Mon, Jul 01, 2019 at 07:09:40PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the char-misc tree got a conflict in: > > > > drivers/hwtracing/coresight/of_coresight.c >

Re: [PATCH v8 26/29] vfio-pci: Register an iommu fault handler

On 10/06/2019 22:31, Jacob Pan wrote: > On Mon, 10 Jun 2019 13:45:02 +0100 > Jean-Philippe Brucker wrote: > >> On 07/06/2019 18:43, Jacob Pan wrote: >>>>> So it seems we agree on the following: >>>>> - iommu_unregister_device_fault_handler() will

[PATCH 2/4] iommu: Introduce device fault data

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

[PATCH 4/4] iommu: Add recoverable fault reporting

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

Re: [PATCH v3 09/16] iommu: Introduce guest PASID bind function

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: >>

Re: [PATCH v3 02/16] iommu: Introduce cache_invalidate API

On 14/05/2019 18:44, Jacob Pan wrote: > Hi Thank you both for the explanation. > > On Tue, 14 May 2019 11:41:24 +0100 > Jean-Philippe Brucker wrote: > >> On 14/05/2019 08:36, Auger Eric wrote: >>> Hi Jacob, >>> >>> On 5/14/19 12:16 AM, Jacob Pan

Re: [PATCH v7 04/23] iommu: Introduce attach/detach_pasid_table API

On 08/04/2019 13:18, Eric Auger wrote: > diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h > index edcc0dda7993..532a64075f23 100644 > --- a/include/uapi/linux/iommu.h > +++ b/include/uapi/linux/iommu.h > @@ -112,4 +112,51 @@ struct iommu_fault { > struct

Re: linux-next: manual merge of the vhost tree with the iommu tree

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,

Re: [PATCH v3 02/16] iommu: Introduce cache_invalidate API

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. >>

Re: [PATCH v5 05/22] iommu: Introduce cache_invalidate API

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 { >>>

Re: [PATCH v4 03/22] iommu: introduce device fault report API

On 06/03/2019 23:46, Jacob Pan wrote: > On Tue, 5 Mar 2019 15:03:41 + > Jean-Philippe Brucker wrote: > >> On 18/02/2019 13:54, Eric Auger wrote: >> [...]> +/** >> > + * iommu_register_device_fault_handler() - Register a device fault >> > handler &

Re: [PATCH v4 02/22] iommu: introduce device fault data

On 06/03/2019 14:30, Auger Eric wrote: >>> +#define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1) >>> +#define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA (1 << 2) >>> + __u32 flags; >>> + __u32 pasid; >>> + __u32 grpid; >>> + __u32 perm; >>> + __u64 addr; >> >> Given that we'll be

Re: [PATCH v4 02/22] iommu: introduce device fault data

On 06/03/2019 09:38, Auger Eric wrote: >>> +struct iommu_fault_unrecoverable { >>> +    __u32   reason; /* enum iommu_fault_reason */ >>> +#define IOMMU_FAULT_UNRECOV_PASID_VALID (1 << 0) >>> +#define IOMMU_FAULT_UNRECOV_PERM_VALID  (1 << 1) >> >> Not needed, since @perm

Re: [PATCH v4 05/22] iommu: Introduce cache_invalidate API

re, > model specific IOMMU drivers need to convert them into their own format. > > Signed-off-by: Liu, Yi L > Signed-off-by: Jean-Philippe Brucker > Signed-off-by: Jacob Pan > Signed-off-by: Ashok Raj > Signed-off-by: Eric Auger > > --- > v3 -> v4: > -

Re: [PATCH v4 04/22] iommu: Introduce attach/detach_pasid_table API

l iommu driver. > > This patch adds a new API to the iommu subsystem that allows > to set/unset the pasid table information. > > A generic iommu_pasid_table_config struct is introduced in > a new iommu.h uapi header. This is going to be used by the VFIO > user API. > > S

Re: [PATCH v4 03/22] iommu: introduce device fault report API

On 18/02/2019 13:54, Eric Auger wrote: [...]> +/** > + * iommu_register_device_fault_handler() - Register a device fault handler > + * @dev: the device > + * @handler: the fault handler > + * @data: private data passed as argument to the handler > + * > + * When an IOMMU fault event is received,

Re: [PATCH v4 02/22] iommu: introduce device fault data

ult or a page request, > also referred to as a recoverable fault. > > We only 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 >

Re: [RFC PATCH v1 05/15] iommu/arm-smmu: Add auxiliary domain support for arm-smmuv2

Hi Jordan, On 01/03/2019 19:38, Jordan Crouse wrote: > Support the new auxiliary domain API for arm-smmuv2 to initialize and > support multiple pagetables for a SMMU device. Since the smmu-v2 hardware > doesn't have any built in support for switching the pagetable base it is > left as an exercise

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

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

Re: [PATCH 1/1] iommu: Bind process address spaces to devices

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

Re: linux-next: manual merge of the vhost tree with the iommu tree

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

Re: [PATCH 1/1] iommu: Bind process address spaces to devices

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

[PATCH 1/1] iommu: Bind process address spaces to devices

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

[PATCH 0/1] IOMMU SVA device driver interface

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

Re: [PATCH v6 0/9] vfio/mdev: IOMMU aware mediated device

Where do > we go from here?  I think we need an ack from Kirti since they have an > interest here.  Presumably this looks ok to the ARM folks. Looks great from my point of view. I focused on patch 1 since I'm planning to reuse iommu_dev_features for SVA. I don't have time to test auxd and

Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management

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_each(pasid, func, data) &g

Re: [PATCH v6 1/9] iommu: Add APIs for multiple domains per device

ite this ID to the device register so that DMA >     requests could be tagged with a right PASID prefix. > > This has been updated with the latest proposal from Joerg > posted here [5]. > > Many people involved in discussions of this design. > > Kevin Tian > Liu Yi L >

Re: [PATCH 2/2] iommu/amd: Remove clear_flush_young notifier

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

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

Hi, On 31/01/2019 13:52, Zhen Lei wrote: > Currently, many peripherals are faster than before. For example, the top > speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But > when iommu page-table mapping enabled, it's hard to reach the top speed > in strict mode, because of

Re: [PATCH 2/2] iommu/amd: Remove clear_flush_young notifier

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, Jean, > >> >> On 30/01/2019 05:57, Peter Xu wrote: >>> AMD IOMMU driver is using the clear_flush_young() to do cache flushing

Re: [PATCH 2/2] iommu/amd: Remove clear_flush_young notifier

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?

Re: [RFC v3 02/21] iommu: Introduce cache_invalidate API

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

Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

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 &g

Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions

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

Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions

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

Re: [RFC v3 14/21] iommu: introduce device fault data

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)

Re: [RFC v3 14/21] iommu: introduce device fault data

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

Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults

On 15/01/2019 21:06, Auger Eric wrote: >>> + iommu_report_device_fault(master->dev, ); >> >> 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 we

Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

specializations of this struct, > for PASID table passing and ARM SMMUv3. Last sentence is a bit confusing. With SMMUv3 it is also used for the PASID table, even when it only has one entry and PASID is disabled. > Signed-off-by: Jean-Philippe Brucker > Signed-off-by: Liu, Yi L &g

Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults

On 08/01/2019 10:26, Eric Auger wrote: > When a stage 1 related fault event is read from the event queue, > let's propagate it to potential external fault listeners, ie. users > who registered a fault handler. > > Signed-off-by: Eric Auger > --- > drivers/iommu/arm-smmu-v3.c | 124

Re: [RFC v3 11/21] iommu/smmuv3: Implement cache_invalidate

On 08/01/2019 10:26, Eric Auger wrote: > Implement IOMMU_INV_TYPE_TLB invalidations. When > nr_pages is null we interpret this as a context > invalidation. > > Signed-off-by: Eric Auger > > --- > > The user API needs to be refined to discriminate context > invalidations from NH_VA

Re: [RFC v3 09/21] iommu/smmuv3: Get prepared for nested stage support

Hi Eric, On 08/01/2019 10:26, Eric Auger wrote: > To allow nested stage support, we need to store both > stage 1 and stage 2 configurations (and remove the former > union). > > arm_smmu_write_strtab_ent() is modified to write both stage > fields in the STE. > > We add a nested_bypass field to

Re: [RFC v3 14/21] iommu: introduce device fault data

ported are grouped >> and generalized based common specifications such as PCI ATS. >> >> 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 >> [moved

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 03/10/2018 09:46, Shameerali Kolothum Thodi wrote: [...] >>> + /* Verify specified event is supported on this PMU */ >>> + event_id = get_event(event); >>> + if (((event_id < SMMU_ARCH_MAX_EVENT_ID) && >>> + (!test_bit(event_id, smmu_pmu->supported_events))) || >>> + (event_id

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 03/10/2018 09:46, Shameerali Kolothum Thodi wrote: [...] >>> + /* Verify specified event is supported on this PMU */ >>> + event_id = get_event(event); >>> + if (((event_id < SMMU_ARCH_MAX_EVENT_ID) && >>> + (!test_bit(event_id, smmu_pmu->supported_events))) || >>> + (event_id

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 02/10/2018 15:11, Jean-Philippe Brucker wrote: >> +cfgr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_CFGR); Something I missed previously: when SMMU_PMCG_CFGR.SID_FILTER_TYPE is 1, filtering for all counters is configured by SMMU_PMCG_SMR0 and SMMU_PMCG_EVTYPER0 (instead of h

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 02/10/2018 15:11, Jean-Philippe Brucker wrote: >> +cfgr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_CFGR); Something I missed previously: when SMMU_PMCG_CFGR.SID_FILTER_TYPE is 1, filtering for all counters is configured by SMMU_PMCG_SMR0 and SMMU_PMCG_EVTYPER0 (instead of h

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

Hi Shameer, I have a few comments below, mostly naive since I don't know anything about perf drivers. On 21/09/2018 16:08, Shameer Kolothum wrote: > From: Neil Leeder > > Adds a new driver to support the SMMUv3 PMU and add it into the > perf events framework. > > Each SMMU node may have

Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

Hi Shameer, I have a few comments below, mostly naive since I don't know anything about perf drivers. On 21/09/2018 16:08, Shameer Kolothum wrote: > From: Neil Leeder > > Adds a new driver to support the SMMUv3 PMU and add it into the > perf events framework. > > Each SMMU node may have

[PATCH] IDR: Add missing XArray include

IDR now exposes the XArray lock to users, and relies on the xa_* macros defined in xarray.h. Include this header in idr.h. Fixes: 3c60e868c31e ("IDR: Expose the XArray lock") Signed-off-by: Jean-Philippe Brucker --- include/linux/idr.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] IDR: Add missing XArray include

IDR now exposes the XArray lock to users, and relies on the xa_* macros defined in xarray.h. Include this header in idr.h. Fixes: 3c60e868c31e ("IDR: Expose the XArray lock") Signed-off-by: Jean-Philippe Brucker --- include/linux/idr.h | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [RFC 01/13] iommu: Introduce bind_guest_stage API

On 04/09/2018 09:41, Auger Eric wrote: > I think the confusion comes from the different terminology used in VTD > and ARM SMMU spec. > > Your PASID table ~ ARM SMMU Context Descriptor (CD) table > Your Root Entry/Context Entry ~ ARM SMMU Stream Table Entry (STE) In past discussions we used

Re: [RFC 01/13] iommu: Introduce bind_guest_stage API

On 04/09/2018 09:41, Auger Eric wrote: > I think the confusion comes from the different terminology used in VTD > and ARM SMMU spec. > > Your PASID table ~ ARM SMMU Context Descriptor (CD) table > Your Root Entry/Context Entry ~ ARM SMMU Stream Table Entry (STE) In past discussions we used

Re: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

hem 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() IOMMU op must now check if the mm argument is NULL, in which case it should al

Re: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

hem 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() IOMMU op must now check if the mm argument is NULL, in which case it should al

Re: [PATCH v2 0/5] add non-strict mode support for arm-smmu-v3

Hi Zhen Lei, On 10/06/18 12:07, Zhen Lei wrote: > v1 -> v2: > Use the lowest bit of the io_pgtable_ops.unmap's iova parameter to pass the > strict mode: > 0, IOMMU_STRICT; > 1, IOMMU_NON_STRICT; > Treat 0 as IOMMU_STRICT, so that the unmap operation can compatible with > other IOMMUs which still

Re: [PATCH v2 0/5] add non-strict mode support for arm-smmu-v3

Hi Zhen Lei, On 10/06/18 12:07, Zhen Lei wrote: > v1 -> v2: > Use the lowest bit of the io_pgtable_ops.unmap's iova parameter to pass the > strict mode: > 0, IOMMU_STRICT; > 1, IOMMU_NON_STRICT; > Treat 0 as IOMMU_STRICT, so that the unmap operation can compatible with > other IOMMUs which still

Re: Difference between IOVA and bus address when SMMU is enabled

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

Re: Difference between IOVA and bus address when SMMU is enabled

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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, Looks mostly good to me, I just have a couple more comments On 04/05/18 19:07, Jacob Pan wrote: > Now the passdown invalidation granularities look like: > (sorted by coarseness), will send out in v5 patchset soon if no issues. > > /** > * enum iommu_inv_granularity - Generic

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, Looks mostly good to me, I just have a couple more comments On 04/05/18 19:07, Jacob Pan wrote: > Now the passdown invalidation granularities look like: > (sorted by coarseness), will send out in v5 patchset soon if no issues. > > /** > * enum iommu_inv_granularity - Generic

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

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

Re: [PATCH v4 12/22] iommu: introduce device fault report API

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

Re: [PATCH v4 12/22] iommu: introduce device fault report API

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

Re: [PATCH v4 14/22] iommu: handle page response timeout

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

Re: [PATCH v4 14/22] iommu: handle page response timeout

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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

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

Re: [PATCH v4 13/22] iommu: introduce page response function

On 23/04/18 13:16, Jacob Pan wrote: > I shall drop these, only put in here to match your patch. i am looking > into converting vt-d svm prq to your queued fault patch. I think it will > give both functional and performance benefit. Thanks, I just rebased my patches onto this series and am hoping

Re: [PATCH v4 13/22] iommu: introduce page response function

On 23/04/18 13:16, Jacob Pan wrote: > I shall drop these, only put in here to match your patch. i am looking > into converting vt-d svm prq to your queued fault patch. I think it will > give both functional and performance benefit. Thanks, I just rebased my patches onto this series and am hoping

Re: [PATCH v4 14/22] iommu: handle page response timeout

On Mon, Apr 16, 2018 at 10:49:03PM +0100, Jacob Pan wrote: > When IO page faults are reported outside IOMMU subsystem, the page > request handler may fail for various reasons. E.g. a guest received > page requests but did not have a chance to run for a long time. The > irresponsive behavior could

Re: [PATCH v4 14/22] iommu: handle page response timeout

On Mon, Apr 16, 2018 at 10:49:03PM +0100, Jacob Pan wrote: > When IO page faults are reported outside IOMMU subsystem, the page > request handler may fail for various reasons. E.g. a guest received > page requests but did not have a chance to run for a long time. The > irresponsive behavior could

Re: [PATCH v4 13/22] iommu: introduce page response function

On Mon, Apr 16, 2018 at 10:49:02PM +0100, Jacob Pan wrote: [...] > + /* > + * Check if we have a matching page request pending to respond, > + * otherwise return -EINVAL > + */ > + list_for_each_entry_safe(evt, iter, >fault_param->faults, list) { I don't think you need the

Re: [PATCH v4 13/22] iommu: introduce page response function

On Mon, Apr 16, 2018 at 10:49:02PM +0100, Jacob Pan wrote: [...] > + /* > + * Check if we have a matching page request pending to respond, > + * otherwise return -EINVAL > + */ > + list_for_each_entry_safe(evt, iter, >fault_param->faults, list) { I don't think you need the

Re: [PATCH v4 12/22] iommu: introduce device fault report API

On Mon, Apr 16, 2018 at 10:49:01PM +0100, Jacob Pan wrote: [...] > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + struct iommu_param *param =

Re: [PATCH v4 12/22] iommu: introduce device fault report API

On Mon, Apr 16, 2018 at 10:49:01PM +0100, Jacob Pan wrote: [...] > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + struct iommu_param *param =

Re: [PATCH v4 10/22] iommu: introduce device fault data

On Mon, Apr 16, 2018 at 10:48:59PM +0100, 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

Re: [PATCH v4 10/22] iommu: introduce device fault data

On Mon, Apr 16, 2018 at 10:48:59PM +0100, 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

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: [...] > > + /* Assign guest PASID table pointer and size order */ > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > Where does this IOMMU API interface

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: [...] > > + /* Assign guest PASID table pointer and size order */ > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > Where does this IOMMU API interface

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [kvmtool PATCH 20/17] kvmtool: arm64: Switch memory layout

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 > --- >

Re: [kvmtool PATCH 20/17] kvmtool: arm64: Switch memory layout

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 + >

Re: [PATCH v3 10/16] iommu: introduce device fault report API

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 > @@

Re: [PATCH v3 10/16] iommu: introduce device fault report API

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 > @@

Re: [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports

On 12/01/18 10:21, Peter Maydell wrote: > On 10 January 2018 at 11:25, Jean-Philippe Brucker > <jean-philippe.bruc...@arm.com> wrote: >> Hi Peter, >> >> On 10/01/18 11:19, Peter Maydell wrote: >>> Are there uses that make it worthwhile to get virtio-1 >&g

Re: [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports

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

Re: [PATCH v3 10/16] iommu: introduce device fault report API

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;> +} > + >

Re: [PATCH v3 10/16] iommu: introduce device fault report API

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;> +} > + >

Re: [PATCH v3 03/16] iommu: introduce iommu invalidate API function

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

Re: [PATCH v3 03/16] iommu: introduce iommu invalidate API function

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

Re: [PATCH v3 08/16] iommu: introduce device fault data

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

Re: [PATCH v3 08/16] iommu: introduce device fault data

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

Re: [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports

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

Re: [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports

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

Re: [PATCH v3 03/16] iommu: introduce iommu invalidate API function

A quick update on invalidations before I leave for holidays, since we're struggling to define useful semantics. I worked on the virtio-iommu prototype for vSVA, so I tried to pin down what I think is needed for vSVA invalidation in the host. I don't know whether the VT-d and AMD emulations can

Re: [PATCH v3 03/16] iommu: introduce iommu invalidate API function

A quick update on invalidations before I leave for holidays, since we're struggling to define useful semantics. I worked on the virtio-iommu prototype for vSVA, so I tried to pin down what I think is needed for vSVA invalidation in the host. I don't know whether the VT-d and AMD emulations can

<    1   2   3   4   >