Skip to content
Snippets Groups Projects
  1. Nov 07, 2023
  2. Oct 25, 2023
  3. Oct 12, 2023
  4. Oct 07, 2023
  5. Aug 31, 2023
  6. Jun 28, 2023
  7. Jun 26, 2023
  8. Jun 20, 2023
  9. Mar 07, 2023
  10. Feb 28, 2023
    • Daniel Henrique Barboza's avatar
      accel/tcg: Add 'size' param to probe_access_flags() · 1770b2f2
      Daniel Henrique Barboza authored
      
      probe_access_flags() as it is today uses probe_access_full(), which in
      turn uses probe_access_internal() with size = 0. probe_access_internal()
      then uses the size to call the tlb_fill() callback for the given CPU.
      This size param ('fault_size' as probe_access_internal() calls it) is
      ignored by most existing .tlb_fill callback implementations, e.g.
      arm_cpu_tlb_fill(), ppc_cpu_tlb_fill(), x86_cpu_tlb_fill() and
      mips_cpu_tlb_fill() to name a few.
      
      But RISC-V riscv_cpu_tlb_fill() actually uses it. The 'size' parameter
      is used to check for PMP (Physical Memory Protection) access. This is
      necessary because PMP does not make any guarantees about all the bytes
      of the same page having the same permissions, i.e. the same page can
      have different PMP properties, so we're forced to make sub-page range
      checks. To allow RISC-V emulation to do a probe_acess_flags() that
      covers PMP, we need to either add a 'size' param to the existing
      probe_acess_flags() or create a new interface (e.g.
      probe_access_range_flags).
      
      There are quite a few probe_* APIs already, so let's add a 'size' param
      to probe_access_flags() and re-use this API. This is done by open coding
      what probe_access_full() does inside probe_acess_flags() and passing the
      'size' param to probe_acess_internal(). Existing probe_access_flags()
      callers use size = 0 to not change their current API usage. 'size' is
      asserted to enforce single page access like probe_access() already does.
      
      No behavioral changes intended.
      
      Signed-off-by: default avatarDaniel Henrique Barboza <dbarboza@ventanamicro.com>
      Message-Id: <20230223234427.521114-2-dbarboza@ventanamicro.com>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      1770b2f2
  11. Oct 06, 2022
  12. Oct 04, 2022
  13. Jul 20, 2022
  14. Jun 27, 2022
  15. Apr 21, 2022
  16. Mar 15, 2022
  17. Mar 06, 2022
  18. Nov 01, 2021
  19. May 02, 2021
  20. Feb 08, 2021
    • David Gibson's avatar
      sev: Remove false abstraction of flash encryption · aacdb844
      David Gibson authored
      
      When AMD's SEV memory encryption is in use, flash memory banks (which are
      initialed by pc_system_flash_map()) need to be encrypted with the guest's
      key, so that the guest can read them.
      
      That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
      state.. except, that it doesn't really abstract much at all.
      
      For starters, the only call site is in code specific to the 'pc'
      family of machine types, so it's obviously specific to those and to
      x86 to begin with.  But it makes a bunch of further assumptions that
      need not be true about an arbitrary confidential guest system based on
      memory encryption, let alone one based on other mechanisms:
      
       * it assumes that the flash memory is defined to be encrypted with the
         guest key, rather than being shared with hypervisor
       * it assumes that that hypervisor has some mechanism to encrypt data into
         the guest, even though it can't decrypt it out, since that's the whole
         point
       * the interface assumes that this encrypt can be done in place, which
         implies that the hypervisor can write into a confidential guests's
         memory, even if what it writes isn't meaningful
      
      So really, this "abstraction" is actually pretty specific to the way SEV
      works.  So, this patch removes it and instead has the PC flash
      initialization code call into a SEV specific callback.
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      aacdb844
  21. Jan 23, 2021
  22. Jan 02, 2021
  23. Nov 16, 2020
  24. Oct 21, 2020
  25. Oct 05, 2020
  26. Sep 30, 2020
Loading