On Thu, Aug 13, 2015 at 03:45:07PM +0100, Suzuki K. Poulose wrote:
> On 13/08/15 13:28, Steve Capper wrote:
> >On 13 August 2015 at 12:34, Suzuki K. Poulose wrote:
> >> __enable_mmu:
> >>+ mrs x1, ID_AA64MMFR0_EL1
> >>+ ubfxx2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4
> >>+ cmp
On 07/10/2015 04:21 PM, Andre Przywara wrote:
> The GICv3 Interrupt Translation Service (ITS) uses tables in memory
> to allow a sophisticated interrupt routing. It features device tables,
> an interrupt table per device and a table connecting "collections" to
> actual CPUs (aka. redistributors in
On 07/10/2015 04:21 PM, Andre Przywara wrote:
> Add emulation for some basic MMIO registers used in the ITS emulation.
> This includes:
> - GITS_{CTLR,TYPER,IIDR}
> - ID registers
> - GITS_{CBASER,CREADR,CWRITER}
> those implement the ITS command buffer handling
>
> Most of the handlers are pret
On 13/08/15 13:28, Steve Capper wrote:
On 13 August 2015 at 12:34, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
Ensure that the selected page size is supported by the
CPU(s).
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/incl
On 07/10/2015 04:21 PM, Andre Przywara wrote:
> The ARM GICv3 ITS emulation code goes into a separate file, but
> needs to be connected to the GICv3 emulation, of which it is an
> option.
> Introduce the skeleton with function stubs to be filled later.
> Introduce the basic ITS data structure and i
On 13 August 2015 at 12:34, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> Ensure that the selected page size is supported by the
> CPU(s).
>
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Suzuki K. Poulose
> ---
> arch/arm64/include/asm/sysreg.h |6
Reviewed-by: Eric Auger
On 07/10/2015 04:21 PM, Andre Przywara wrote:
> The ARM GICv3 ITS controller requires a separate register frame to
> cover ITS specific registers. Add a new VGIC address type and store
> the address in a field in the vgic_dist structure.
> Provide a function to check wheth
On 07/10/2015 04:21 PM, Andre Przywara wrote:
> In the GICv3 redistributor there are the PENDBASER and PROPBASER
> registers which we did not emulate so far, as they only make sense
> when having an ITS. In preparation for that emulate those MMIO
> accesses by storing the 64-bit data written into i
From: "Suzuki K. Poulose"
We use !CONFIG_ARM64_64K_PAGES for CONFIG_ARM64_4K_PAGES
(and vice versa) in code. It all worked well, so far since
we only had two options. Now, with the introduction of 16K,
these cases will break. This patch cleans up the code to
use the required CONFIG symbol express
From: "Suzuki K. Poulose"
36bit VA lets us use 2 level page tables while limiting the
available address space to 64GB.
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/Kconfig |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
From: "Suzuki K. Poulose"
Rearrange the code for fake pgd handling, which is applicable
to only ARM64. The intention is to keep the common code cleaner,
unaware of the underlying hacks.
Cc: kvmarm@lists.cs.columbia.edu
Cc: christoffer.d...@linaro.org
Cc: marc.zyng...@arm.com
Signed-off-by: Suzuk
From: "Suzuki K. Poulose"
Now that we can calculate the number of levels required for
mapping a va width, reserve exact number of pages that would
be required to cover the idmap. The idmap should be able to handle
the maximum physical address size supported.
Cc: Ard Biesheuvel
Cc: Mark Rutland
From: "Suzuki K. Poulose"
Move the kernel pagetable (both swapper and idmap) definitions
from the generic asm/page.h to a new file, asm/kernel-pgtable.h.
This is mostly a cosmetic change, to clean up the asm/page.h to
get rid of the arch specific details which are not needed by the
generic code.
From: "Suzuki K. Poulose"
At the moment, we only support maximum of 3-level page table for
swapper. With 48bit VA, 64K has only 3 levels and 4K uses section
mapping. Add support for 4-level page table for swapper, needed
by 16K pages.
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Catalin Marinas
Cc
From: "Suzuki K. Poulose"
This patch turns on the 16K page support in the kernel. We
support 48bit VA (4 level page tables) and 47bit VA (3 level
page tables).
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Steve Capper
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/Kconfig
From: "Suzuki K. Poulose"
Ensure that the selected page size is supported by the
CPU(s).
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/include/asm/sysreg.h |6 ++
arch/arm64/kernel/head.S| 24 +++-
From: "Suzuki K. Poulose"
{V}TCR_EL2_TG0 is a 2bit wide field, where:
00 - 4K
01 - 64K
10 - 16K
But we use only 1 bit, which has worked well so far since
we never cared about 16K. Fix it for 16K support.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: kvmar
From: "Suzuki K. Poulose"
No functional changes. Group the common bits for VCTR_EL2
initialisation for better readability. The granule size
and the entry level are controlled by the page size.
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Suzuki K. Poulo
From: "Suzuki K. Poulose"
We use section maps with 4K page size to create the
swapper/idmaps. So far we have used !64K or 4K checks
to handle the case where we use the section maps. This
patch adds a symbol to make it clear those cases.
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Catalin Marinas
From: "Suzuki K. Poulose"
Introduce helpers for finding the number of page table
levels required for a given VA width, shift for a particular
page table level.
Convert the existing users to the new helpers. More users
to follow.
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Wil
From: "Suzuki K. Poulose"
Update the help text for ARM64_64K_PAGES to reflect the reality
about AArch32 support.
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
From: "Suzuki K. Poulose"
The existing fake pgd handling code assumes that the stage-2 entry
level can only be one level down that of the host, which may not be
true always(e.g, with the introduction of 16k pagesize).
e.g.
With 16k page size and 48bit VA and 40bit IPA we have the following
split
From: "Suzuki K. Poulose"
This series enables the 16K page size support on Linux for arm64.
This series adds support for 48bit VA(4 level), 47bit VA(3 level) and
36bit VA(2 level) with 16K. 16K was a late addition to the architecture
and is not implemented by all CPUs. Added a check to ensure the
Hi Alex,
On 08/12/2015 09:05 PM, Alex Williamson wrote:
> On Mon, 2015-08-10 at 15:31 +0200, Eric Auger wrote:
>> This patch adds the registration/unregistration of an
>> irq_bypass_consumer on irqfd assignment/deassignment.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Feng Wu
>>
>> ---
>>
>
So far, GICv2 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and w
Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU") added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, an
Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU") added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, an
The GICv2 and GICv3 architectures allow an active physical interrupt
to be forwarded to a guest, and the guest to indirectly perform the
deactivation of the interrupt by performing an EOI on the virtual
interrupt (see for example the GICv2 spec, 3.2.1).
This allows some substantial performance imp
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and w
29 matches
Mail list logo
