On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
>
> This one's a bit tricky to find a home for - I think technically it's
> probably an IOMMU patch, but then the long-underlying problem doesn't
> seem to have blown up anything until arm64, and my motivation is to
> make bits of Juno work,
2014-12-12 23:14+0800, Feng Wu:
> This patch defines a new interface kvm_find_dest_vcpu for
> VT-d PI, which can returns the destination vCPU of the
> interrupt for guests.
>
> Since VT-d PI cannot handle broadcast/multicast interrupt,
> Here we only handle Fixed and Lowest priority interrupts.
>
2015-01-09 15:56+0100, Paolo Bonzini:
>
>
> On 09/01/2015 15:54, Radim Krčmář wrote:
> > There are two points relevant to this patch in new KVM's implementation,
> > ("KVM: x86: amend APIC lowest priority arbitration",
> > https://lkml.org/lkml/2015/1/9/362)
> >
> > 1) lowest priority depends o
2015-01-09 16:18+0100, Paolo Bonzini:
> On 09/01/2015 16:12, Radim Krčmář wrote:
> > > The chipset doesn't support it. :(
> >
> > I meant that we need to recompute PI entries for lowest priority
> > interrupts every time guest's TPR changes.
> >
> > Luckily, Linux doesn't use TPR, but other OS mi
Many DMA controllers and other devices set max_segment_size to
indicate their scatter-gather capability, but have no interest in
segment_boundary_mask. However, the existence of a dma_parms structure
precludes the use of any default value, leaving them as zeros (assuming
a properly kzalloc'ed struc
On Thu, Jan 8, 2015 at 4:24 PM, Arnd Bergmann wrote:
> On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:
>> On 01/08/2015 03:40 AM, Arnd Bergmann wrote:
>> > On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
>> >> On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri
>> >> wrote:
>
[adding Marek, Sjoerd and Joonyoung that were discussing about iommu
support in another thread]
Hello Hongbo,
On Fri, Jan 9, 2015 at 8:31 AM, Hongbo Zhang wrote:
> Add linux-samsung-...@vger.kernel.org mailing list.
>
> On 7 January 2015 at 18:31, Hongbo Zhang wrote:
>> Hi Cho KyongHo, Joerg et
On 09/01/2015 16:12, Radim Krčmář wrote:
> > The chipset doesn't support it. :(
>
> I meant that we need to recompute PI entries for lowest priority
> interrupts every time guest's TPR changes.
>
> Luckily, Linux doesn't use TPR, but other OS might be a reason to drop
> lowest priority from PI
On 09/01/2015 15:54, Radim Krčmář wrote:
> There are two points relevant to this patch in new KVM's implementation,
> ("KVM: x86: amend APIC lowest priority arbitration",
> https://lkml.org/lkml/2015/1/9/362)
>
> 1) lowest priority depends on TPR
> 2) there is no need for balancing
>
> (1) has
> -Original Message-
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Friday, January 09, 2015 8:46 PM
> To: Wu, Feng
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> alex.william...@redhat.
A number of IOMMUs found in ARM SoCs can walk architecture-compatible
page tables.
This patch adds a generic allocator for Stage-1 and Stage-2 v7/v8
long-descriptor page tables. 4k, 16k and 64k pages are supported, with
up to 4-levels of walk to cover a 48-bit address space.
Tested-by: Laurent Pi
Hello,
This is version two of the patch series I originally posted here:
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306786.html
Changes since v1 include:
- Separated 32-bit and 64-bit regimes
- Limited pgd allocation when a full page is not required
- Addition
This patch adds a series of basic self-consistency tests to the ARM LPAE
IO page table allocator that exercise corner cases in map/unmap, as well
as testing all valid configurations of pagesize, ias and stage.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig | 9 ++
drivers/iommu/
The ARM SMMU can walk LPAE page tables, so make use of the generic
allocator.
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig | 1 -
drivers/iommu/Kconfig| 6 +-
drivers/iommu/arm-smmu.c | 886 ++-
3 files changed, 266 insertions(+), 62
This patch introduces a generic framework for allocating page tables for
an IOMMU. There are a number of reasons we want to do this:
- It avoids duplication of complex table management code in IOMMU
drivers that use the same page table format
- It removes any coupling with the CPU table f
From: Laurent Pinchart
The quirk causes the Non-Secure bit to be set in all page table entries.
Signed-off-by: Laurent Pinchart
Signed-off-by: Will Deacon
---
drivers/iommu/io-pgtable-arm.c | 7 +++
drivers/iommu/io-pgtable.h | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
d
Hi Feng,
On Tue, Jan 06, 2015 at 01:10:19AM +, Wu, Feng wrote:
> Ping...
>
> Hi Joerg & David,
>
> Could you please have a look at the IOMMU part of this series (patch 02 - 04,
> patch 06 - 09 , patch 26)?
>
> Hi Thomas, Ingo, & Peter,
>
> Could you please have a look at this series, espe
On Wed, Jan 07, 2015 at 03:31:27PM +0800, Jiang Liu wrote:
> This patch set is based on v3.19-rc3. And you may access it at:
> https://github.com/jiangliu/linux.git ir_init_v2
I tested this branch on an AMD system, everything looks good so far. I
couldn't find any regressions. So feel free to add
On Wed, Dec 24, 2014 at 09:10:41AM +0800, Mark Zhang wrote:
> This patch adds suspend/resume support for NVIDIA SMMU.
>
> Signed-off-by: Mark Zhang
> ---
> Hi Alex/Olof/Thierry/Hiroshi,
>
> This patch is created on top of Thierry Reding's patch set:
> "[PATCH v7 00/12] NVIDIA Tegra memory contro
On Fri, Jan 9, 2015 at 9:39 AM, Eric Auger wrote:
> Hi Antonios,
>
> when moving to 3.19rc3 I observe a regression with my xgmac use case
> (real-time change?).
>
> I guess what happens is when I kill a first qemu session, guest does not
> have time to complete the virtual IRQ and the unmask is no
On Thu, Jan 08, 2015 at 10:25:15PM +, Arnd Bergmann wrote:
> On Thursday 08 January 2015 14:52:13 Murali Karicheri wrote:
> >
> > Could you add this as as a follow up patch as I don't have a platformm
> > that support IOMMU and as such my understanding of the IOMMU is limited?
> >
> > I can
On Thu, Jan 08, 2015 at 04:15:42PM +0200, Oded Gabbay wrote:
> Hi Thierry,
> Generally I agree with the issues you describe in the current design.
> One task in our 2015 workplan is to change the whole method amdkfd is
> loaded, so it can independently load at any time, regardless of the order of
>
Hi Antonios,
when moving to 3.19rc3 I observe a regression with my xgmac use case
(real-time change?).
I guess what happens is when I kill a first qemu session, guest does not
have time to complete the virtual IRQ and the unmask is not performed by
the virqfd handler. When starting a new QEMU ses
23 matches
Mail list logo
