1. 05 11月, 2014 5 次提交
  2. 25 10月, 2014 1 次提交
  3. 24 10月, 2014 1 次提交
  4. 22 10月, 2014 2 次提交
  5. 21 10月, 2014 8 次提交
  6. 16 10月, 2014 1 次提交
  7. 15 10月, 2014 1 次提交
  8. 14 10月, 2014 1 次提交
    • C
      arm64: KVM: Implement 48 VA support for KVM EL2 and Stage-2 · 38f791a4
      Christoffer Dall 提交于
      This patch adds the necessary support for all host kernel PGSIZE and
      VA_SPACE configuration options for both EL2 and the Stage-2 page tables.
      
      However, for 40bit and 42bit PARange systems, the architecture mandates
      that VTCR_EL2.SL0 is maximum 1, resulting in fewer levels of stage-2
      pagge tables than levels of host kernel page tables.  At the same time,
      systems with a PARange > 42bit, we limit the IPA range by always setting
      VTCR_EL2.T0SZ to 24.
      
      To solve the situation with different levels of page tables for Stage-2
      translation than the host kernel page tables, we allocate a dummy PGD
      with pointers to our actual inital level Stage-2 page table, in order
      for us to reuse the kernel pgtable manipulation primitives.  Reproducing
      all these in KVM does not look pretty and unnecessarily complicates the
      32-bit side.
      
      Systems with a PARange < 40bits are not yet supported.
      
       [ I have reworked this patch from its original form submitted by
         Jungseok to take the architecture constraints into consideration.
         There were too many changes from the original patch for me to
         preserve the authorship.  Thanks to Catalin Marinas for his help in
         figuring out a good solution to this challenge.  I have also fixed
         various bugs and missing error code handling from the original
         patch. - Christoffer ]
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      38f791a4
  9. 11 10月, 2014 1 次提交
  10. 10 10月, 2014 5 次提交
  11. 06 10月, 2014 1 次提交
  12. 04 10月, 2014 3 次提交
    • L
      arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format() · 65ba758f
      Laszlo Ersek 提交于
      An example log excerpt demonstrating the change:
      
      Before the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data]
      >   0x000040001000-0x00004007ffff [Conventional Memory]
      >   0x000040080000-0x00004072afff [Loader Data]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory]
      >   0x0000964e9000-0x0000964e9fff [Loader Data]
      >   0x0000964ea000-0x000096c52fff [Loader Code]
      >   0x000096c53000-0x00009709dfff [Boot Code]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data]*
      >   0x0000970f5000-0x000097117fff [Runtime Code]*
      >   0x000097118000-0x000097199fff [Runtime Data]*
      >   0x00009719a000-0x0000971dffff [Runtime Code]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory]
      >   0x0000997f9000-0x0000998f1fff [Boot Data]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory]
      >   0x0000999eb000-0x00009af09fff [Boot Data]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory]
      >   0x00009af22000-0x00009af46fff [Boot Data]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory]
      >   0x00009af5c000-0x00009afe1fff [Boot Data]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory]
      >   0x00009afe3000-0x00009c01ffff [Boot Data]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory]
      >   0x00009efc0000-0x00009f14efff [Boot Code]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code]*
      >   0x00009f163000-0x00009f194fff [Runtime Data]*
      >   0x00009f195000-0x00009f197fff [Boot Data]*
      >   0x00009f198000-0x00009f198fff [Runtime Data]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory]
      >   0x00009f1ad000-0x00009f1affff [Boot Data]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O]
      
      After the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      
      The attribute bitmap is now displayed, in decoded form.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      65ba758f
    • D
      arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefi · 6632210f
      Dave Young 提交于
      In case efi runtime disabled via noefi kernel cmdline
      arm64_enter_virtual_mode should error out.
      
      At the same time move early_memunmap(memmap.map, mapsize) to the
      beginning of the function or it will leak early mem.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      6632210f
    • D
      arm64/efi: uefi_init error handling fix · 88f8abd5
      Dave Young 提交于
      There's one early memmap leak in uefi_init error path, fix it and
      slightly tune the error handling code.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Acked-by: NMark Salter <msalter@redhat.com>
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      88f8abd5
  13. 03 10月, 2014 7 次提交
  14. 02 10月, 2014 3 次提交