On Mon, Sep 30, 2013 at 7:39 PM, Alex Williamson wrote:
> On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> > A VFIO userspace driver will start by opening the VFIO device
> > that corresponds to an IOMMU group, and will use the ioctl interface
> > to get the basic device info, such as
On Mon, Sep 30, 2013 at 7:39 PM, Alex Williamson wrote:
> On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> > The VFIO documentation is slightly out of date. This minor correction
> > replaces references to VFIO_IOMMU_X86 with the correct reference to
> > VFIO_IOMMU_TYPE1
> >
> > Signe
On Mon, Sep 30, 2013 at 5:49 PM, Bhushan Bharat-R65777 wrote:
>
>
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
> > Sent: Monday, September 30, 2013 8:59 PM
> > To: kvm...@list
On Mon, Sep 30, 2013 at 7:39 PM, Alex Williamson
wrote:
>
> On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> > This is a workaround to make the VFIO_IOMMU_TYPE1 driver usable with
> > platform devices instead of PCI. A future permanent fix should support
> > both. This is required in o
On Mon, Sep 30, 2013 at 9:41 PM, Alex Williamson
wrote:
>
> On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> > Platform devices in the Linux kernel are usually managed by the DT
> > interface. This patch forms the base to support these kind of devices
> > with VFIO.
> >
> > Signed-off-
Hi,
here a reworked set of patches. Hopefully all comments addressed.
I omitted the patch "ARM: dma-mapping: Always pass proper prot flags
to iommu_map()" as it is pushed by Marek to the dma-mapping fixes
branch.
I also omitted the device isolation patch (have to think about your
comment(s) and
There is already a check to print a warning if the size of SMMU
address space (calculated from SMMU register values) is greater than
the size of the mapped memory region (e.g. passed via DT to the
driver).
Adapt this check to print also a warning in case the mapped region is
larger than the SMMU a
With the right (or wrong;-) definition of v1 SMMU node in DTB it is
possible to trigger a division by zero in arm_smmu_init_domain_context
(if number of context irqs is 0):
if (smmu->version == 1) {
root_cfg->irptndx = atomic_inc_return(&smmu->irptndx);
=>root_cf
This should ensure that arm-smmu is initialized before other drivers
start handling devices that propably need smmu support.
Signed-off-by: Andreas Herrmann
---
drivers/iommu/arm-smmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iomm
Print context fault information when the fault was not handled by
report_iommu_fault.
Signed-off-by: Andreas Herrmann
---
drivers/iommu/arm-smmu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 7d07561..579b6f8 100644
--- a/dri
In such a case we have to use secure aliases of some non-secure
registers.
This behaviour is controlled via a flag in smmu->bugs. It is set
based on DT information when probing an SMMU device.
Signed-off-by: Andreas Herrmann
---
drivers/iommu/arm-smmu.c | 33 -
After reset these registers have unknown values.
This might cause problems when evaluating SMMU_GFSR and/or SMMU_CB_FSR
in handlers for combined interrupts.
Signed-off-by: Andreas Herrmann
---
drivers/iommu/arm-smmu.c | 31 ---
1 file changed, 20 insertions(+), 11 d
On 10/01/2013 07:39 AM, Andreas Herrmann wrote:
> In such a case we have to use secure aliases of some non-secure
> registers.
>
> This behaviour is controlled via a flag in smmu->bugs. It is set
> based on DT information when probing an SMMU device.
Perhaps quirks would be a nicer word...
>
>
On Tue, Oct 01, 2013 at 01:39:04PM +0100, Andreas Herrmann wrote:
> Hi,
>
> here a reworked set of patches. Hopefully all comments addressed.
Cheers Andreas! I've taken the first 5. Whilst I like the cleanup you've
made to the final patch, I'll need an Ack from Rob until I can take anything
conta
On Tue, Oct 1, 2013 at 5:47 PM, Christoffer Dall
wrote:
> On Mon, Sep 30, 2013 at 05:28:36PM +0200, Antonios Motakis wrote:
>> This is a preview of the base work, towards VFIO support on ARM platforms
>> with an IOMMU. It forms a base on to which to implement the functionality
>> necessary to enab
On Tue, Oct 01, 2013 at 09:28:51AM -0400, Rob Herring wrote:
> On 10/01/2013 07:39 AM, Andreas Herrmann wrote:
> > In such a case we have to use secure aliases of some non-secure
> > registers.
> >
> > This behaviour is controlled via a flag in smmu->bugs. It is set
> > based on DT information whe
On Tue, Oct 01, 2013 at 11:50:09AM -0400, Will Deacon wrote:
> On Tue, Oct 01, 2013 at 01:39:04PM +0100, Andreas Herrmann wrote:
> > Hi,
> >
> > here a reworked set of patches. Hopefully all comments addressed.
>
> Cheers Andreas! I've taken the first 5.
Cool, thanks!
> Whilst I like the cleanu
> > static int __init vfio_iommu_type1_init(void)
> > {
> > - if (!iommu_present(&pci_bus_type))
> > +#ifdef CONFIG_PCI
> > + if (iommu_present(&pci_bus_type)) {
> > + iommu_bus_type = &pci_bus_type;
> > + /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> > +
> Antonios Motakis wrote
> > Alex Williamson wrote:
> > I notice all the open firmware calls here and I'm curious,
> > will all platform devices be making use of open firmware?
> > I don't know if this is synonymous with device tree or not.
> > Thanks,
>
> This VFIO driver will support only device
On Tue, 2013-10-01 at 19:32 +, Yoder Stuart-B08248 wrote:
> > Antonios Motakis wrote
> > > Alex Williamson wrote:
> > > I notice all the open firmware calls here and I'm curious,
> > > will all platform devices be making use of open firmware?
> > > I don't know if this is synonymous with devic
20 matches
Mail list logo
