ne 27, 2014 1:47 AM
> To: Alex Williamson
> Cc: Chalamarla, Tirumalesh; Joerg Roedel; k...@vger.kernel.org; open list;
> stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
> t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
> SMMU DRIVER; marc.zyng.
04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
Thanks for the clarification Alex, That’s exactly my point, why are
we relying on QEMU or something
list:ARM
SMMU DRIVER; marc.zyng...@arm.com
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
> On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
> > Thanks for the clarifica
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
> On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
> > Thanks for the clarification Alex, That’s exactly my point, why are we
> > relying on QEMU or something else to emulate the MSI space when we can
> > directly
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
Thanks for the clarification Alex, That’s exactly my point, why are we
relying on QEMU or something else to emulate the MSI space when we can
directly give
list:ARM
SMMU DRIVER; marc.zyng...@arm.com
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
Thanks for the clarification Alex, That’s
cale.com; io...@lists.linux-foundation.org;
> t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
> SMMU DRIVER
> Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
> IOMMU_CAP_INTR_REMAP
>
> On Thu, 2014-06-26 at 18:41 +, Chalamarla, T
...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, 2014-06-26 at 18:41 +, Chalamarla, Tirumalesh wrote:
> Sorry there was a type,
>
> The question is:
>
> How is V
Cc: k...@vger.kernel.org; open list; alex.william...@redhat.com;
> stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
> t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
> SMMU DRIVER
> Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
>
...@vger.kernel.org; open list; alex.william...@redhat.com;
stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
Forgive me if this discussion is not relative here, but I thought it is.
How is VFIO restricting devices from writing to MSI/MSI-X, Is all the vector
area is mapped by VFIO to trap the accesses. I am asking
v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote:
> Ok, thanks. In which case, I think this is really a combined property
> of the SMMU and the interrupt controller, so we might need some extra
> code so that the
v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote:
Ok, thanks. In which case, I think this is really a combined property
of the SMMU and the interrupt controller, so we might need some extra
code so that the SMMU can
Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
Forgive me if this discussion is not relative here, but I thought it is.
How is VFIO restricting devices from writing to MSI/MSI-X, Is all the vector
area is mapped by VFIO to trap the accesses. I am asking
...@vger.kernel.org; open list; alex.william...@redhat.com;
stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
...@redhat.com;
stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
When I say emulating ITS, I mean translating
...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, 2014-06-26 at 18:41 +, Chalamarla, Tirumalesh wrote:
Sorry there was a type,
The question is:
How is VFIO restricting software
...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated list:ARM
SMMU DRIVER
Subject: Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability
IOMMU_CAP_INTR_REMAP
On Thu, 2014-06-26 at 18:41 +, Chalamarla, Tirumalesh wrote:
Sorry there was a type,
The question is:
How is VFIO
On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote:
> Ok, thanks. In which case, I think this is really a combined property of
> the SMMU and the interrupt controller, so we might need some extra code
> so that the SMMU can check that the interrupt controller for the device
> is also
On Mon, 2014-06-16 at 17:21 +0200, Joerg Roedel wrote:
> On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
> > MSIs look just like memory accesses made by the device, so the SMMU
> > will translate them to point at the GIC ITS (doorbell). The ITS then
> > has tables to work out how to
On Mon, Jun 16, 2014 at 04:21:58PM +0100, Joerg Roedel wrote:
> On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
> > MSIs look just like memory accesses made by the device, so the SMMU
> > will translate them to point at the GIC ITS (doorbell). The ITS then
> > has tables to work out
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
> MSIs look just like memory accesses made by the device, so the SMMU
> will translate them to point at the GIC ITS (doorbell). The ITS then
> has tables to work out how to route the MSI.
>
> So, if IOMMU_CAP_INTR_REMAP is simply
On Mon, Jun 16, 2014 at 03:53:44PM +0100, Joerg Roedel wrote:
> On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
> > On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
> > > With an ARM SMMU, interrupt remapping should always be safe from the
> > > SMMU's point of
On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
> On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
> > With an ARM SMMU, interrupt remapping should always be safe from the
> > SMMU's point of view, as it is properly handled by the GIC.
> >
> > Signed-off-by:
On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
With an ARM SMMU, interrupt remapping should always be safe from the
SMMU's point of view, as it is properly handled by the GIC.
Signed-off-by: Antonios
On Mon, Jun 16, 2014 at 03:53:44PM +0100, Joerg Roedel wrote:
On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
With an ARM SMMU, interrupt remapping should always be safe from the
SMMU's point of view, as
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
MSIs look just like memory accesses made by the device, so the SMMU
will translate them to point at the GIC ITS (doorbell). The ITS then
has tables to work out how to route the MSI.
So, if IOMMU_CAP_INTR_REMAP is simply supposed to
On Mon, Jun 16, 2014 at 04:21:58PM +0100, Joerg Roedel wrote:
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
MSIs look just like memory accesses made by the device, so the SMMU
will translate them to point at the GIC ITS (doorbell). The ITS then
has tables to work out how to
On Mon, 2014-06-16 at 17:21 +0200, Joerg Roedel wrote:
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
MSIs look just like memory accesses made by the device, so the SMMU
will translate them to point at the GIC ITS (doorbell). The ITS then
has tables to work out how to route
On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote:
Ok, thanks. In which case, I think this is really a combined property of
the SMMU and the interrupt controller, so we might need some extra code
so that the SMMU can check that the interrupt controller for the device
is also capable
On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
> With an ARM SMMU, interrupt remapping should always be safe from the
> SMMU's point of view, as it is properly handled by the GIC.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1
On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
With an ARM SMMU, interrupt remapping should always be safe from the
SMMU's point of view, as it is properly handled by the GIC.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/iommu/arm-smmu.c |
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
> Sent: Thursday, June 05, 2014 10:33 PM
> To: alex.william...@redhat.com; kvm...@lists.cs.columbia.edu;
>
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
Sent: Thursday, June 05, 2014 10:33 PM
To: alex.william...@redhat.com; kvm...@lists.cs.columbia.edu;
io...@lists.linux-foundation.org
34 matches
Mail list logo
