Re: [PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes

Alex, > On Wed, 8 Jun 2016 10:29:35 +0200 > Auger Eric <eric.au...@linaro.org> wrote: > >> Dear all, >> Le 20/05/2016 à 18:01, Eric Auger a écrit : >>> Alex, Robin, >>> >>> While my 3 part series primarily addresses the problemati

Re: [PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes

Dear all, Le 20/05/2016 à 18:01, Eric Auger a écrit : > Alex, Robin, > > While my 3 part series primarily addresses the problematic of mapping > MSI doorbells into arm-smmu, it fails in : > > 1) determining whether the MSI controller is downstream or upstream to > the IOMMU, > => indicates

Re: [RESEND PATCH v2 0/6] vfio-pci: Add support for mmapping MSI-X table

Hi Yongji, Le 02/06/2016 à 08:09, Yongji Xie a écrit : > Current vfio-pci implementation disallows to mmap the page > containing MSI-X table in case that users can write directly > to MSI-X table and generate an incorrect MSIs. > > However, this will cause some performance issue when there > are

Re: [PATCH V6 5/8] vfio: platform: call _RST method when using ACPI

Hi Sinan, Le 29/05/2016 à 00:01, Sinan Kaya a écrit : > The device tree code checks for the presence of a reset driver and calls > the of_reset function pointer by looking up the reset driver as a module. > > ACPI defines _RST method to perform device level reset. After the _RST > method is

Re: [PATCH V6 7/8] vfio: platform: check reset call return code during open

Hi Sinan, Le 29/05/2016 à 00:01, Sinan Kaya a écrit : > Open call is ignoring the return code from reset call and can > potentially continue even though reset call failed. > > If reset_required module parameter is set, this patch is going > to validate the return code and will abort open if reset

Re: [PATCH V6 6/8] vfio, platform: make reset driver a requirement by default

Le 29/05/2016 à 00:01, Sinan Kaya a écrit : > The code was allowing platform devices to be used without a supporting > VFIO reset driver. The hardware can be left in some inconsistent state > after a guest machine abort. > > The reset driver will put the hardware back to safe state and disable

Re: [PATCH V6 8/8] vfio: platform: check reset call return code during release

Hi Sinan, Le 29/05/2016 à 00:01, Sinan Kaya a écrit : > Release call is ignoring the return code from reset call and can > potentially continue even though reset call failed. > > If reset_required module parameter is set, this patch is going > to validate the return code and will cause stack dump

Re: [PATCH V5 4/6] vfio: platform: add support for ACPI probe

Hi Sinan, Le 23/05/2016 à 15:18, Eric Auger a écrit : > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The code is using the compatible DT string to associate a reset driver >> with the actual device itself. The compatible string does not exist on >> ACPI based systems. HID is the unique identifier

Re: [PATCH v10 4/8] vfio/type1: handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Hello, Le 07/06/2016 à 18:44, kbuild test robot a écrit : > Hi, > > [auto build test ERROR on vfio/next] > [also build test ERROR on v4.7-rc2 next-20160607] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

Wei, Le 13/06/2016 à 13:18, Robin Murphy a écrit : > On 13/06/16 10:20, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will create a single iommu group for this >>

Re: [PATCH V3] vfio: platform: support No-IOMMU mode

Hi Peng Le 23/05/2016 à 11:47, Peng Fan a écrit : > The vfio No-IOMMU mode was supported by this > 'commit 03a76b60f8ba2797 ("vfio: Include No-IOMMU mode")', > but it only support vfio-pci. > > Using vfio_iommu_group_get/put, but not iommu_group_get/put, > the platform devices can be exposed to

Re: [PATCH V7 8/9] vfio: platform: check reset call return code during open

Hi Sinan, On 13/06/2016 06:26, Sinan Kaya wrote: > Open call is ignoring the return code from reset call and can > potentially continue even though reset call failed. > > If reset_required module parameter is set, this patch is going > to validate the return code and will abort open if reset

Re: [PATCH v10 7/9] irqchip/gicv3-its: register the MSI global doorbell

Hi Jean-Philippe, On 17/06/2016 18:33, Jean-Philippe Brucker wrote: > Hi Eric, > > On Tue, Jun 07, 2016 at 04:01:26PM +, Eric Auger wrote: >> This patch adds the registration of the MSI global doorbell in >> gicv3-its driver. >> >> This will allow the msi layer to iommu_map this doorbell

Re: [PATCH V7 7/9] vfio, platform: make reset driver a requirement by default

Hi Sinan, On 13/06/2016 06:26, Sinan Kaya wrote: > The code was allowing platform devices to be used without a supporting > VFIO reset driver. The hardware can be left in some inconsistent state > after a guest machine abort. > > The reset driver will put the hardware back to safe state and

Re: [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe

Hi Thomas, On 22/07/2016 14:44, Thomas Gleixner wrote: > On Thu, 21 Jul 2016, Auger Eric wrote: >> On 20/07/2016 10:12, Thomas Gleixner wrote: >>> On Tue, 19 Jul 2016, Eric Auger wrote: >>>> +bool msi_doorbell_safe(void) >>>> +{ >>>> + s

Re: [PATCH] iommu/iova: validate iova_domain input to put_iova_domain

Hi Robin, Nate, On 14/07/2016 12:36, Robin Murphy wrote: > On 14/07/16 09:34, Joerg Roedel wrote: >> On Wed, Jul 13, 2016 at 02:49:32PM -0400, Nate Watterson wrote: >>> Passing a NULL or uninitialized iova_domain into put_iova_domain >>> will currently crash the kernel when the unconfigured

Re: [PATCH v11 4/8] iommu/msi-iommu: initialization

Hi Dennis, On 20/07/2016 13:43, Dennis Chen wrote: > Hi Eric, > Some small questions/comments below: > > On Tue, Jul 19, 2016 at 12:55:07PM +, Eric Auger wrote: >> iommu_get/put_msi_cookie allocates/frees the resource used to store >> and ref count the MSI doorbell mappings.

Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested

Hi Thomas, On 26/07/2016 11:04, Thomas Gleixner wrote: > Eric, > > On Mon, 25 Jul 2016, Auger Eric wrote: >> On 20/07/2016 11:09, Thomas Gleixner wrote: >>> On Tue, 19 Jul 2016, Eric Auger wrote: >>>> @@ -63,10 +63,18 @@ static int msi_compose(struct irq_dat

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

Hi Thomas, On 26/07/2016 11:00, Thomas Gleixner wrote: > B1;2802;0cEric, > > On Mon, 25 Jul 2016, Auger Eric wrote: >> On 20/07/2016 11:04, Thomas Gleixner wrote: >>> On Tue, 19 Jul 2016, Eric Auger wrote: >>>> + if (ret) { >

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

Hi Thomas, On 20/07/2016 11:04, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> /** >> + * msi_handle_doorbell_mappings: in case the irq data corresponds to an >> + * MSI that requires iommu mapping, traverse the irq domain hierarchy >> + * to retrieve the doorbells to handle

Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested

Hi Thomas, On 20/07/2016 11:09, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: > > First of all - valid for all patches: > > Subject: sys/subsys: Sentence starts with an uppercase letter OK understood. > > Now for this particular one: > > genirq/msi: use the MSI doorbell's

Re: [PATCH v11 4/8] vfio/type1: handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Hi, On 24/07/2016 03:41, kbuild test robot wrote: > Hi, > > [auto build test ERROR on vfio/next] > [also build test ERROR on v4.7-rc7 next-20160722] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH v12 02/11] genirq/msi: msi_compose wrapper

Hi Thomas, On 09/08/2016 11:19, Thomas Gleixner wrote: > On Tue, 2 Aug 2016, Eric Auger wrote: > >> Currently the MSI message is composed by directly calling >> irq_chip_compose_msi_msg and erased by setting the memory to zero. >> >> On some platforms, we will need to complexify this composition

Re: [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages

Hi Thomas, On 19/07/2016 16:38, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> msi_doorbell_pages sum up the number of iommu pages of a given order > > adding () to the function name would make it immediately clear that > msi_doorbell_pages is a function. > >> +/** >> + *

Re: [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe

Hi, On 20/07/2016 10:12, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> +bool msi_doorbell_safe(void) >> +{ >> +struct irqchip_doorbell *db; >> +bool irq_remapping = true; >> + >> +mutex_lock(_doorbell_mutex); >> +list_for_each_entry(db, _doorbell_list, next) {

Re: [PATCH v11 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

Hi Dennis On 20/07/2016 11:56, Dennis Chen wrote: > Hi Eric, > > On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote: >> This series introduces the msi-iommu api used to: >> >> - allocate/free resources for MSI IOMMU mapping >> - set the MSI iova window aperture >> - map/unmap physical

Re: [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages

Hi Thomas, On 19/07/2016 16:38, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> msi_doorbell_pages sum up the number of iommu pages of a given order > > adding () to the function name would make it immediately clear that > msi_doorbell_pages is a function. > >> +/** >> + *

Re: [PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration

Hi Thomas, On 19/07/2016 16:22, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> + >> +#include >> +#include >> +#include >> + >> +struct irqchip_doorbell { >> +struct irq_chip_msi_doorbell_info info; >> +struct list_head next; > > Again, please align the struct

Re: [PATCH v12 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes

Hi Diana, On 05/08/2016 16:46, Diana Madalina Craciun wrote: > Hi Eric, > > I have tested these patches in a VFIO PCI scenario (using the ITS > emulation) on a NXP LS2080 board. It worked fine with one e1000 card > assigned to the guest. However, when I tried to assign two cards to the > guest I

Re: [PATCH v12 09/11] genirq/msi: Introduce msi_desc flags

Hi, On 02/08/2016 19:23, Eric Auger wrote: > This new flags member is meant to store additional information about > the msi descriptor, starting with allocation status information. > > MSI_DESC_FLAG_ALLOCATED bit tells the associated base IRQ is allocated. > This information is currently used at

Re: [PATCH] KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice

Hi Shanker, On 03/02/2017 03:30, Shanker Donthineni wrote: > The IRQFD framework calls the architecture dependent function > twice if the corresponding GSI type is edge triggered. For ARM, > the function kvm_set_msi() is getting called twice whenever the > IRQFD receives the event signal. The rest

Re: [PATCH v9 08/18] iommu/vt-d: Implement reserved region get/put callbacks

Hi Will, On 23/01/2017 12:46, Will Deacon wrote: > [adding David Woodhouse, since he maintains this driver] Thank you for adding David to the list. Whoever is likely to pull this, please let me know if I need to respin to add missed Will's Acked-by. Thanks Eric > > Will > > On Thu, Jan 19,

Re: [RFC PATCH 07/33] irqchip/gic-v3-its: Macro-ize its_send_single_command

On 17/01/2017 11:20, Marc Zyngier wrote: > Most ITS commands do operate on a collection object, and require > a SYNC command to be performed on that collection in order to > guarantee the execution of the first command. > > With GICv4 ITS, another set of commands perform similar operations > on

Re: [RFC PATCH 08/33] irqchip/gic-v3-its: Implement irq_set_irqchip_state for pending state

On 17/01/2017 11:20, Marc Zyngier wrote: > Allow the pending state of an LPI to be set or cleared via > irq_set_irqchip_state. > > Signed-off-by: Marc Zyngier Reviewed-by: Eric Auger Eric > --- > drivers/irqchip/irq-gic-v3-its.c | 78 >

Re: [RFC PATCH 10/33] irqchip/gic-v4-its: Allow use of indirect VCPU tables

Hi Marc, On 17/01/2017 11:20, Marc Zyngier wrote: > The VCPU tables can be quite sparse as well, and it makes sense > to use indirect tables as well if possible. > > Signed-off-by: Marc Zyngier > --- > drivers/irqchip/irq-gic-v3-its.c | 20 +--- > 1 file

Re: [RFC PATCH 09/33] irqchip/gic-v3-its: Split out property table allocation

Hi Marc, On 17/01/2017 11:20, Marc Zyngier wrote: > Move the LPI property table allocation into its own function, as > this is going to be required for those associated with VMs in > the future. > > Signed-off-by: Marc Zyngier > --- > drivers/irqchip/irq-gic-v3-its.c | 28

Re: [RFC PATCH 03/33] irqchip/gic-v3-its: Refactor command encoding

On 17/01/2017 11:20, Marc Zyngier wrote: > The way we encode the various ITS command fields is both tedious > and error prone. Let's introduce a helper function that performs > the encoding, and convert the existing encoders to use that > helper. > > Signed-off-by: Marc Zyngier

Re: [RFC PATCH 02/33] irqchip/gic-v3: Add VLPI/DirectLPI discovery

Hi, On 17/01/2017 11:20, Marc Zyngier wrote: > Add helper functions that probe for VLPI and DirectLPI properties. > > Signed-off-by: Marc Zyngier Besides the returned value previous questions, Reviewed-by: Eric Auger Eric > --- >

Re: [RFC PATCH 04/33] irqchip/gic-v3-its: Move LPI definitions around

Hi Marc, On 17/01/2017 11:20, Marc Zyngier wrote: > The various LPI definitions are in the middle of the code, and > would be better placed at the beginning, given that we're going > to use some of them much earlier. > > Signed-off-by: Marc Zyngier Reviewed-by: Eric Auger

Re: [RFC PATCH 06/33] irqchip/gic-v3-its: Add probing for VLPI properties

Hi, On 13/02/2017 11:00, Thomas Gleixner wrote: > On Tue, 17 Jan 2017, Marc Zyngier wrote: >> +typer = gic_read_typer(its_base + GITS_TYPER); >> its->base = its_base; >> its->phys_base = res->start; >> -its->ite_size = ((gic_read_typer(its_base + GITS_TYPER) >> 4) & 0xf) + >>

Re: [RFC PATCH 01/33] irqchip/gic-v3: Add redistributor iterator

Hi Marc, On 17/01/2017 11:20, Marc Zyngier wrote: > In order to discover the VLPI properties, we need to iterate over > the redistributor regions. As we already have code that does this, > let's factor it out and make it slightly more generic. > > Signed-off-by: Marc Zyngier

Re: [RFC PATCH 08/33] irqchip/gic-v3-its: Implement irq_set_irqchip_state for pending state

Marc, On 17/01/2017 11:20, Marc Zyngier wrote: > Allow the pending state of an LPI to be set or cleared via > irq_set_irqchip_state. > > Signed-off-by: Marc Zyngier Reviewed-by: Eric Auger Eric > --- > drivers/irqchip/irq-gic-v3-its.c | 78 >

Re: [RFC PATCH 07/33] irqchip/gic-v3-its: Macro-ize its_send_single_command

Hi, On 17/01/2017 11:20, Marc Zyngier wrote: > Most ITS commands do operate on a collection object, and require > a SYNC command to be performed on that collection in order to > guarantee the execution of the first command. > > With GICv4 ITS, another set of commands perform similar operations >

Re: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Tomasz, On 13/01/2017 14:59, Tomasz Nowicki wrote: > Hello Eric, > > On 11.01.2017 10:41, Eric Auger wrote: >> Following LPC discussions, we now report reserved regions through >> the iommu-group sysfs reserved_regions attribute file. >> >> Reserved regions are populated through the IOMMU

Re: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Tomasz, On 13/01/2017 14:59, Tomasz Nowicki wrote: > Hello Eric, > > On 11.01.2017 10:41, Eric Auger wrote: >> Following LPC discussions, we now report reserved regions through >> the iommu-group sysfs reserved_regions attribute file. >> >> Reserved regions are populated through the IOMMU

Re: [PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap

Hi Tomasz, On 17/01/2017 14:40, Tomasz Nowicki wrote: > On 11.01.2017 10:41, Eric Auger wrote: >> This new function checks whether all MSI irq domains >> implement IRQ remapping. This is useful to understand >> whether VFIO passthrough is safe with respect to interrupts. >> >> On ARM typically an

Re: [PATCH] vfio/pci: Fix NULL pointer oops in error interrupt setup handling

Hi Alex, On 02/08/2016 22:00, Alex Williamson wrote: > There are multiple cases in vfio_pci_set_ctx_trigger_single() where > we assume we can safely read from our data pointer without actually > checking whether the user has passed any data via the count field. > VFIO_IRQ_SET_DATA_NONE in

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Hi, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Check only if irq domains are available. > > Signed-off-by: Mian Yousaf Kaukab > --- > drivers/vfio/vfio_iommu_type1.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Hi Mian Yousaf, On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' >

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Hi Marc, On 02/03/2017 11:16, Marc Zyngier wrote: > On 02/03/17 10:01, Mian Yousaf Kaukab wrote: >> Fix following build error for s390: >> drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': >> drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of >>

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

Hi, On 02/03/2017 13:38, Mian Yousaf Kaukab wrote: > On 03/02/2017 11:24 AM, Auger Eric wrote: >> Hi, >> >> On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: >>> Check only if irq domains are available. >>> >>> Signed-off-by: Mian Yousaf Kaukab <

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

Hi Yousaf, On 02/03/2017 13:23, Mian Yousaf Kaukab wrote: > On 03/02/2017 11:24 AM, Auger Eric wrote: >> Hi Mian Yousaf, >> >> On 02/03/2017 11:01, Mian Yousaf Kaukab wrote: >>> Fix following build error for s390: >>> drivers/vfio/vfio_iommu_type1.c: In func

Re: [PATCH v5 19/19] iommu/dma: Add support for mapping MSIs

Hi Robin, On 26/08/2016 03:17, Robin Murphy wrote: > Hi Eric, > > On Fri, 26 Aug 2016 00:25:34 +0200 > Auger Eric <eric.au...@redhat.com> wrote: > >> Hi Robin, >> >> On 23/08/2016 21:05, Robin Murphy wrote: >>> When an MSI doorbell is locat

Re: [PATCH] vfio: platform: mark symbols static where possible

Hi Baoyou, On 01/09/2016 13:15, Baoyou Xie wrote: > We get a few warnings when building kernel with W=1: > drivers/vfio/platform/vfio_platform_common.c:76:5: warning: no previous > prototype for 'vfio_platform_acpi_call_reset' [-Wmissing-prototypes] >

Re: [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed

Hi Robin, On 04/10/2016 19:18, Robin Murphy wrote: > On 02/10/16 10:56, Christoffer Dall wrote: >> On Fri, Sep 30, 2016 at 02:24:40PM +0100, Robin Murphy wrote: >>> Hi Eric, >>> >>> On 27/09/16 21:48, Eric Auger wrote: iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on

Re: [PATCH v13 03/15] iommu/dma: Allow MSI-only cookies

Hi Alex, On 06/10/2016 22:17, Alex Williamson wrote: > On Thu, 6 Oct 2016 08:45:19 + > Eric Auger wrote: > >> From: Robin Murphy >> >> IOMMU domain users such as VFIO face a similar problem to DMA API ops >> with regard to mapping MSI messages

Re: [PATCH v13 04/15] genirq/msi: Introduce the MSI doorbell API

Hi Alex, On 06/10/2016 22:17, Alex Williamson wrote: > On Thu, 6 Oct 2016 08:45:20 + > Eric Auger wrote: > >> We introduce a new msi-doorbell API that allows msi controllers >> to allocate and register their doorbells. This is useful when >> those doorbells are

Re: [PATCH v13 11/15] vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Hi Alex, On 06/10/2016 22:19, Alex Williamson wrote: > On Thu, 6 Oct 2016 08:45:27 + > Eric Auger wrote: > >> Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots, >> let's implement the expected behavior for removal and replay. >> >> As opposed to

Re: [PATCH v13 12/15] vfio: Allow reserved msi iova registration

Hi Alex, On 06/10/2016 22:19, Alex Williamson wrote: > On Thu, 6 Oct 2016 08:45:28 + > Eric Auger wrote: > >> The user is allowed to register a reserved MSI IOVA range by using the >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. >> This

Re: [PATCH v13 15/15] vfio/type1: Return the MSI geometry through VFIO_IOMMU_GET_INFO capability chains

Hi Alex, On 06/10/2016 22:42, Alex Williamson wrote: > On Thu, 6 Oct 2016 14:20:40 -0600 > Alex Williamson wrote: > >> On Thu, 6 Oct 2016 08:45:31 + >> Eric Auger wrote: >> >>> This patch allows the user-space to retrieve the MSI

Re: [PATCH V11 0/8] Introduce ACPI world to ITS irqchip

Hi, On 12/09/2016 20:32, Tomasz Nowicki wrote: > The series builds the PCI/MSI domain stack based on initial IORT driver > which is added in first place. As a reference please see IORT spec: > http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf > > Tested on

Re: [PATCH v5 19/19] iommu/dma: Add support for mapping MSIs

Hi Robin, On 23/08/2016 21:05, Robin Murphy wrote: > When an MSI doorbell is located downstream of an IOMMU, attaching > devices to a DMA ops domain and switching on translation leads to a rude > shock when their attempt to write to the physical address returned by > the irqchip driver faults (or

Re: [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed

Hi Robin, On 30/09/2016 15:24, Robin Murphy wrote: > Hi Eric, > > On 27/09/16 21:48, Eric Auger wrote: >> iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on >> IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap >> they reserve the IOVA window to prevent the iova allocator

Re: Summary of LPC guest MSI discussion in Santa Fe

Hi Will, On 08/11/2016 03:45, Will Deacon wrote: > Hi all, > > I figured this was a reasonable post to piggy-back on for the LPC minutes > relating to guest MSIs on arm64. > > On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote: >> We can always have QEMU reject hot-adding the

Re: Summary of LPC guest MSI discussion in Santa Fe

Hi, On 10/11/2016 00:59, Alex Williamson wrote: > On Wed, 9 Nov 2016 23:38:50 + > Will Deacon wrote: > >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote: >>> On Wed, 9 Nov 2016 22:25:22 + >>> Will Deacon wrote: >>> On

Re: Summary of LPC guest MSI discussion in Santa Fe

Hi Will, On 08/11/2016 20:02, Don Dutile wrote: > On 11/08/2016 12:54 PM, Will Deacon wrote: >> On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote: >>> On 08/11/2016 03:45, Will Deacon wrote: >>>> Rather than treat these as separate problems, a better inter

Re: [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain

Hi Robin, On 10/11/2016 12:54, Robin Murphy wrote: > Hi Eric, > > On 10/11/16 11:22, Auger Eric wrote: >> Hi Robin, >> >> On 04/11/2016 15:00, Robin Murphy wrote: >>> Hi Eric, >>> >>> Thanks for posting this new series - the bottom-up approac

Re: [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain

Hi Robin, On 04/11/2016 15:00, Robin Murphy wrote: > Hi Eric, > > Thanks for posting this new series - the bottom-up approach is a lot > easier to reason about :) > > On 04/11/16 11:24, Eric Auger wrote: >> Introduce a new iommu_reserved_region struct. This embodies >> an IOVA reserved region

Re: Summary of LPC guest MSI discussion in Santa Fe

Hi Will, Alex, On 10/11/2016 03:01, Will Deacon wrote: > On Wed, Nov 09, 2016 at 05:55:17PM -0700, Alex Williamson wrote: >> On Thu, 10 Nov 2016 01:14:42 +0100 >> Auger Eric <eric.au...@redhat.com> wrote: >>> On 10/11/2016 00:59, Alex Williamson wrote: >>

Re: [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range

Hi Joerg, On 10/11/2016 16:22, Joerg Roedel wrote: > On Fri, Nov 04, 2016 at 11:24:00AM +, Eric Auger wrote: >> Fix the size check within start_pfn and limit_pfn. >> >> Signed-off-by: Eric Auger >> >> --- >> >> the issue was observed when playing with 1 page iova

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 10/11/2016 16:46, Joerg Roedel wrote: > On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: >> The function populates the list of reserved regions with the >> PCI host bridge windows and the MSI IOVA range. >> >> At the moment an arbitray MSI IOVA window is set at 0x800

Re: [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain

Hi Joerg, Robin, On 10/11/2016 16:37, Joerg Roedel wrote: > On Fri, Nov 04, 2016 at 11:24:02AM +, Eric Auger wrote: >> Introduce a new iommu_reserved_region struct. This embodies >> an IOVA reserved region that cannot be used along with the IOMMU >> API. The list is protected by a dedicated

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 10/11/2016 17:13, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 04:57:51PM +0100, Auger Eric wrote: >> It does not only serve the purpose to register the MSI IOVA region. We >> also need to allocate an iova_domain where MSI IOVAs will be allocated >> upon the re

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 11/11/2016 12:42, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 07:00:52PM +0100, Auger Eric wrote: >> GICv2m and GICV3 ITS use dma-mapping iommu_dma_map_msi_msg to allocate >> an MSI IOVA on-demand. > > Yes, and it the right thing to do there because as a DMA

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 14/11/2016 16:31, Joerg Roedel wrote: > Hi Eric, > > On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote: >> On 11/11/2016 17:22, Joerg Roedel wrote: >>> So I think we need a way to tell userspace about the reserved regions >>> (per iommu-gro

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 14/11/2016 17:20, Joerg Roedel wrote: > On Mon, Nov 14, 2016 at 05:08:16PM +0100, Auger Eric wrote: >> There are potentially several MSI doorbell physical pages in the SOC >> that are accessed through the IOMMU (translated). Each of those must >> have a correspon

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Bharat, On 18/11/2016 06:34, Bharat Bhushan wrote: > Hi Eric, > > Have you sent out QEMU side patches based on this new approach? In case I > missed please point me the patches? Upstream QEMU works fine for PCIe/MSI passthrough on ARM since mach virt address space does not collide with

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

Hi Joerg, On 11/11/2016 17:22, Joerg Roedel wrote: > Hi Eric, > > On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote: >> Effectively in passthrough use case, the userspace defines the address >> space layout and maps guest RAM PA=IOVA to PAs (using

Re: [PATCH v14 14/22] vfio_pci: Update vfio_pci to use vfio_info_add_capability()

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Update msix_sparse_mmap_cap() to use vfio_info_add_capability() > Update region type capability to use vfio_info_add_capability() > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id:

Re: [Qemu-devel] [PATCH v14 13/22] vfio: Introduce common function to add capabilities

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Vendor driver using mediated device framework should use > vfio_info_add_capability() to add capabilities. > Introduced this function to reduce code duplication in vendor drivers. > > vfio_info_cap_shift() manipulated a data buffer to add an

Re: [PATCH v14 17/22] vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Updated vfio_platform_common.c file to use > vfio_set_irqs_validate_and_prepare() > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id: Id87cd6b78ae901610b39bf957974baa6f40cd7b0 > --- >

Re: [PATCH v14 16/22] vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Updated vfio_pci.c file to use vfio_set_irqs_validate_and_prepare() > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id: I9f3daba89d8dba5cb5b01a8cff420412f30686c7 > --- >

Re: [PATCH v14 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare()

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Vendor driver using mediated device framework would use same mechnism to > validate and prepare IRQs. Introducing this function to reduce code > replication in multiple drivers. > > Signed-off-by: Kirti Wankhede >

Re: [PATCH v14 08/22] vfio iommu type1: Add find_iommu_group() function

Hi, On 16/11/2016 21:46, Kirti Wankhede wrote: > Add find_iommu_group() > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Reviewed-by: Jike Song > Reviewed-by: Dong Jia Shi > > Change-Id:

Re: [PATCH v14 08/22] vfio iommu type1: Add find_iommu_group() function

nd noticed that later :-( Anyway I needed (and still need) to look at it. Thanks Eric > > Thanks, > Kirti > > On 11/21/2016 4:59 PM, Auger Eric wrote: >> Hi, >> On 16/11/2016 21:46, Kirti Wankhede wrote: >>> Add find_iommu_group() >>> >>>

Re: [RFC v2 3/8] iommu/dma: Allow MSI-only cookies

Hi Robin, On 14/11/2016 13:36, Robin Murphy wrote: > On 04/11/16 11:24, Eric Auger wrote: >> From: Robin Murphy >> >> IOMMU domain users such as VFIO face a similar problem to DMA API ops >> with regard to mapping MSI messages in systems where the MSI write is >> subject to

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

Hi Will, On 20/10/2016 19:32, Will Deacon wrote: > Hi Eric, > > Thanks for posting this. > > On Wed, Oct 12, 2016 at 01:22:08PM +, Eric Auger wrote: >> This is the second respin on top of Robin's series [1], addressing Alex' >> comments. >> >> Major changes are: >> - MSI-doorbell API now

Re: [PATCH v14 14/16] vfio/type1: Check doorbell safety

Hi Diana, On 03/11/2016 14:45, Diana Madalina Craciun wrote: > Hi Eric, > > On 10/12/2016 04:23 PM, Eric Auger wrote: >> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted >> by the msi controller. >> >> Since we currently have no way to detect whether the MSI controller

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

Hi Robin, On 24/10/2016 21:39, Robin Murphy wrote: > On 21/10/16 10:26, Auger Eric wrote: >> Hi Will, >> >> On 20/10/2016 19:32, Will Deacon wrote: >>> Hi Eric, >>> >>> Thanks for posting this. >>> >>> On Wed, Oct 12, 2016 at

Re: [PATCH v13 03/15] iommu/dma: Allow MSI-only cookies

Hi Robin, On 10/10/2016 16:26, Robin Murphy wrote: > Hi Alex, Eric, > > On 06/10/16 21:17, Alex Williamson wrote: >> On Thu, 6 Oct 2016 08:45:19 + >> Eric Auger wrote: >> >>> From: Robin Murphy >>> >>> IOMMU domain users such as VFIO face a

Re: [PATCH v13 15/15] vfio/type1: Return the MSI geometry through VFIO_IOMMU_GET_INFO capability chains

Hi Alex, On 07/10/2016 22:38, Alex Williamson wrote: > On Fri, 7 Oct 2016 19:10:27 +0200 > Auger Eric <eric.au...@redhat.com> wrote: > >> Hi Alex, >> >> On 06/10/2016 22:42, Alex Williamson wrote: >>> On Thu, 6 Oct 2016 14:20:40 -0600 >>>

Re: [PATCH v14 04/16] iommu/dma: MSI doorbell alloc/free

Hi Punit, On 14/10/2016 13:25, Punit Agrawal wrote: > Hi Eric, > > One query and a comment below. > > Eric Auger writes: > >> We introduce the capability to (un)register MSI doorbells. >> >> A doorbell region is characterized by its physical address base, size, >> and

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

Hi Punit, On 14/10/2016 13:24, Punit Agrawal wrote: > Hi Eric, > > I am a bit late in joining, but I've tried to familiarise > myself with earlier discussions on the series. > > Eric Auger writes: > >> This is the second respin on top of Robin's series [1], addressing

Re: [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks

Hi Robin, On 07/12/2016 19:24, Robin Murphy wrote: > On 07/12/16 15:02, Auger Eric wrote: >> Hi Robin, >> On 06/12/2016 19:55, Robin Murphy wrote: >>> On 15/11/16 13:09, Eric Auger wrote: >>>> The get() populates the list with the PCI host bridge

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Robin, On 08/12/2016 14:14, Robin Murphy wrote: > On 08/12/16 09:36, Auger Eric wrote: >> Hi, >> >> On 15/11/2016 14:09, Eric Auger wrote: >>> Following LPC discussions, we now report reserved regions through >>> iommu-group sysfs reserved_regions attribu

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi, On 15/11/2016 14:09, Eric Auger wrote: > Following LPC discussions, we now report reserved regions through > iommu-group sysfs reserved_regions attribute file. While I am respinning this series into v4, here is a tentative summary of technical topics for which no consensus was reached at

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Shanker, On 07/12/2016 19:52, Shanker Donthineni wrote: > Hi Eric, > > Is there any reason why you are not supporting SMMUv3 driver? Qualcomm > hardware doesn't not support SMMUv2 hardware, please add support for > SMMUv3 in next patch set. I've ported ' RFC,v3,09/10] iommu/arm-smmu: >

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Don, On 11/12/2016 03:05, Don Dutile wrote: > On 12/08/2016 04:36 AM, Auger Eric wrote: >> Hi, >> >> On 15/11/2016 14:09, Eric Auger wrote: >>> Following LPC discussions, we now report reserved regions through >>> iommu-group sysfs reserved_regi

Re: [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks

Hi Robin, On 06/12/2016 19:55, Robin Murphy wrote: > On 15/11/16 13:09, Eric Auger wrote: >> The get() populates the list with the PCI host bridge windows >> and the MSI IOVA range. >> >> At the moment an arbitray MSI IOVA window is set at 0x800 >> of size 1MB. This will allow to report those

Re: [PATCH] vfio-mdev: Fix mtty sample driver building

Hi, On 14/12/2016 20:39, Alex Williamson wrote: > This sample driver was originally under Documentation/ and was moved > to samples, but build support was never adjusted for the new location. > > Signed-off-by: Alex Williamson > --- > samples/Kconfig|

  1   2   3   4   5   6   7   8   9   10   >