1. 21 1月, 2015 1 次提交
  2. 16 1月, 2015 3 次提交
  3. 13 12月, 2014 1 次提交
    • C
      arm/arm64: KVM: Clarify KVM_ARM_VCPU_INIT ABI · f7fa034d
      Christoffer Dall 提交于
      It is not clear that this ioctl can be called multiple times for a given
      vcpu.  Userspace already does this, so clarify the ABI.
      
      Also specify that userspace is expected to always make secondary and
      subsequent calls to the ioctl with the same parameters for the VCPU as
      the initial call (which userspace also already does).
      
      Add code to check that userspace doesn't violate that ABI in the future,
      and move the kvm_vcpu_set_target() function which is currently
      duplicated between the 32-bit and 64-bit versions in guest.c to a common
      static function in arm.c, shared between both architectures.
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      f7fa034d
  4. 24 9月, 2014 2 次提交
    • T
      kvm: Add arch specific mmu notifier for page invalidation · fe71557a
      Tang Chen 提交于
      This will be used to let the guest run while the APIC access page is
      not pinned.  Because subsequent patches will fill in the function
      for x86, place the (still empty) x86 implementation in the x86.c file
      instead of adding an inline function in kvm_host.h.
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fe71557a
    • A
      kvm: Fix page ageing bugs · 57128468
      Andres Lagar-Cavilla 提交于
      1. We were calling clear_flush_young_notify in unmap_one, but we are
      within an mmu notifier invalidate range scope. The spte exists no more
      (due to range_start) and the accessed bit info has already been
      propagated (due to kvm_pfn_set_accessed). Simply call
      clear_flush_young.
      
      2. We clear_flush_young on a primary MMU PMD, but this may be mapped
      as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
      This required expanding the interface of the clear_flush_young mmu
      notifier, so a lot of code has been trivially touched.
      
      3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
      the access bit by blowing the spte. This requires proper synchronizing
      with MMU notifier consumers, like every other removal of spte's does.
      Signed-off-by: NAndres Lagar-Cavilla <andreslc@google.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      57128468
  5. 29 8月, 2014 3 次提交
  6. 28 8月, 2014 1 次提交
  7. 11 7月, 2014 2 次提交
  8. 30 4月, 2014 1 次提交
  9. 03 3月, 2014 1 次提交
  10. 22 12月, 2013 1 次提交
  11. 14 10月, 2013 1 次提交
  12. 03 10月, 2013 1 次提交
  13. 27 6月, 2013 2 次提交
  14. 19 5月, 2013 1 次提交
    • M
      ARM: KVM: move GIC/timer code to a common location · 7275acdf
      Marc Zyngier 提交于
      As KVM/arm64 is looming on the horizon, it makes sense to move some
      of the common code to a single location in order to reduce duplication.
      
      The code could live anywhere. Actually, most of KVM is already built
      with a bunch of ugly ../../.. hacks in the various Makefiles, so we're
      not exactly talking about style here. But maybe it is time to start
      moving into a less ugly direction.
      
      The include files must be in a "public" location, as they are accessed
      from non-KVM files (arch/arm/kernel/asm-offsets.c).
      
      For this purpose, introduce two new locations:
      - virt/kvm/arm/ : x86 and ia64 already share the ioapic code in
        virt/kvm, so this could be seen as a (very ugly) precedent.
      - include/kvm/  : there is already an include/xen, and while the
        intent is slightly different, this seems as good a location as
        any
      
      Eventually, we should probably have independant Makefiles at every
      levels (just like everywhere else in the kernel), but this is just
      the first step.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      7275acdf
  15. 29 4月, 2013 4 次提交
    • M
      ARM: KVM: promote vfp_host pointer to generic host cpu context · 3de50da6
      Marc Zyngier 提交于
      We use the vfp_host pointer to store the host VFP context, should
      the guest start using VFP itself.
      
      Actually, we can use this pointer in a more generic way to store
      CPU speficic data, and arm64 is using it to dump the whole host
      state before switching to the guest.
      
      Simply rename the vfp_host field to host_cpu_context, and the
      corresponding type to kvm_cpu_context_t. No change in functionnality.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <cdall@cs.columbia.edu>
      3de50da6
    • M
      ARM: KVM: add architecture specific hook for capabilities · 17b1e31f
      Marc Zyngier 提交于
      Most of the capabilities are common to both arm and arm64, but
      we still need to handle the exceptions.
      
      Introduce kvm_arch_dev_ioctl_check_extension, which both architectures
      implement (in the 32bit case, it just returns 0).
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <cdall@cs.columbia.edu>
      17b1e31f
    • M
      ARM: KVM: switch to a dual-step HYP init code · 5a677ce0
      Marc Zyngier 提交于
      Our HYP init code suffers from two major design issues:
      - it cannot support CPU hotplug, as we tear down the idmap very early
      - it cannot perform a TLB invalidation when switching from init to
        runtime mappings, as pages are manipulated from PL1 exclusively
      
      The hotplug problem mandates that we keep two sets of page tables
      (boot and runtime). The TLB problem mandates that we're able to
      transition from one PGD to another while in HYP, invalidating the TLBs
      in the process.
      
      To be able to do this, we need to share a page between the two page
      tables. A page that will have the same VA in both configurations. All we
      need is a VA that has the following properties:
      - This VA can't be used to represent a kernel mapping.
      - This VA will not conflict with the physical address of the kernel text
      
      The vectors page seems to satisfy this requirement:
      - The kernel never maps anything else there
      - The kernel text being copied at the beginning of the physical memory,
        it is unlikely to use the last 64kB (I doubt we'll ever support KVM
        on a system with something like 4MB of RAM, but patches are very
        welcome).
      
      Let's call this VA the trampoline VA.
      
      Now, we map our init page at 3 locations:
      - idmap in the boot pgd
      - trampoline VA in the boot pgd
      - trampoline VA in the runtime pgd
      
      The init scenario is now the following:
      - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
        runtime stack, runtime vectors
      - Enable the MMU with the boot pgd
      - Jump to a target into the trampoline page (remember, this is the same
        physical page!)
      - Now switch to the runtime pgd (same VA, and still the same physical
        page!)
      - Invalidate TLBs
      - Set stack and vectors
      - Profit! (or eret, if you only care about the code).
      
      Note that we keep the boot mapping permanently (it is not strictly an
      idmap anymore) to allow for CPU hotplug in later patches.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <cdall@cs.columbia.edu>
      5a677ce0
    • M
      ARM: KVM: add support for minimal host vs guest profiling · 210552c1
      Marc Zyngier 提交于
      In order to be able to correctly profile what is happening on the
      host, we need to be able to identify when we're running on the guest,
      and log these events differently.
      
      Perf offers a simple way to register callbacks into KVM. Mimic what
      x86 does and enjoy being able to profile your KVM host.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <cdall@cs.columbia.edu>
      210552c1
  16. 07 3月, 2013 4 次提交
  17. 25 2月, 2013 1 次提交
  18. 12 2月, 2013 3 次提交
  19. 24 1月, 2013 7 次提交
    • M
      KVM: ARM: Power State Coordination Interface implementation · aa024c2f
      Marc Zyngier 提交于
      Implement the PSCI specification (ARM DEN 0022A) to control
      virtual CPUs being "powered" on or off.
      
      PSCI/KVM is detected using the KVM_CAP_ARM_PSCI capability.
      
      A virtual CPU can now be initialized in a "powered off" state,
      using the KVM_ARM_VCPU_POWER_OFF feature flag.
      
      The guest can use either SMC or HVC to execute a PSCI function.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      aa024c2f
    • C
      KVM: ARM: Handle I/O aborts · 45e96ea6
      Christoffer Dall 提交于
      When the guest accesses I/O memory this will create data abort
      exceptions and they are handled by decoding the HSR information
      (physical address, read/write, length, register) and forwarding reads
      and writes to QEMU which performs the device emulation.
      
      Certain classes of load/store operations do not support the syndrome
      information provided in the HSR.  We don't support decoding these (patches
      are available elsewhere), so we report an error to user space in this case.
      
      This requires changing the general flow somewhat since new calls to run
      the VCPU must check if there's a pending MMIO load and perform the write
      after userspace has made the data available.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      45e96ea6
    • C
      KVM: ARM: User space API for getting/setting co-proc registers · 1138245c
      Christoffer Dall 提交于
      The following three ioctls are implemented:
       -  KVM_GET_REG_LIST
       -  KVM_GET_ONE_REG
       -  KVM_SET_ONE_REG
      
      Now we have a table for all the cp15 registers, we can drive a generic
      API.
      
      The register IDs carry the following encoding:
      
      ARM registers are mapped using the lower 32 bits.  The upper 16 of that
      is the register group type, or coprocessor number:
      
      ARM 32-bit CP15 registers have the following id bit patterns:
        0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
      
      ARM 64-bit CP15 registers have the following id bit patterns:
        0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
      
      For futureproofing, we need to tell QEMU about the CP15 registers the
      host lets the guest access.
      
      It will need this information to restore a current guest on a future
      CPU or perhaps a future KVM which allow some of these to be changed.
      
      We use a separate table for these, as they're only for the userspace API.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      1138245c
    • C
      KVM: ARM: Emulation framework and CP15 emulation · 5b3e5e5b
      Christoffer Dall 提交于
      Adds a new important function in the main KVM/ARM code called
      handle_exit() which is called from kvm_arch_vcpu_ioctl_run() on returns
      from guest execution. This function examines the Hyp-Syndrome-Register
      (HSR), which contains information telling KVM what caused the exit from
      the guest.
      
      Some of the reasons for an exit are CP15 accesses, which are
      not allowed from the guest and this commit handles these exits by
      emulating the intended operation in software and skipping the guest
      instruction.
      
      Minor notes about the coproc register reset:
      1) We reserve a value of 0 as an invalid cp15 offset, to catch bugs in our
         table, at cost of 4 bytes per vcpu.
      
      2) Added comments on the table indicating how we handle each register, for
         simplicity of understanding.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      5b3e5e5b
    • C
      KVM: ARM: World-switch implementation · f7ed45be
      Christoffer Dall 提交于
      Provides complete world-switch implementation to switch to other guests
      running in non-secure modes. Includes Hyp exception handlers that
      capture necessary exception information and stores the information on
      the VCPU and KVM structures.
      
      The following Hyp-ABI is also documented in the code:
      
      Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
         Switching to Hyp mode is done through a simple HVC #0 instruction. The
         exception vector code will check that the HVC comes from VMID==0 and if
         so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
         - r0 contains a pointer to a HYP function
         - r1, r2, and r3 contain arguments to the above function.
         - The HYP function will be called with its arguments in r0, r1 and r2.
         On HYP function return, we return directly to SVC.
      
      A call to a function executing in Hyp mode is performed like the following:
      
              <svc code>
              ldr     r0, =BSYM(my_hyp_fn)
              ldr     r1, =my_param
              hvc #0  ; Call my_hyp_fn(my_param) from HYP mode
              <svc code>
      
      Otherwise, the world-switch is pretty straight-forward. All state that
      can be modified by the guest is first backed up on the Hyp stack and the
      VCPU values is loaded onto the hardware. State, which is not loaded, but
      theoretically modifiable by the guest is protected through the
      virtualiation features to generate a trap and cause software emulation.
      Upon guest returns, all state is restored from hardware onto the VCPU
      struct and the original state is restored from the Hyp-stack onto the
      hardware.
      
      SMP support using the VMPIDR calculated on the basis of the host MPIDR
      and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
      
      Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
      a separate patch into the appropriate patches introducing the
      functionality. Note that the VMIDs are stored per VM as required by the ARM
      architecture reference manual.
      
      To support VFP/NEON we trap those instructions using the HPCTR. When
      we trap, we switch the FPU.  After a guest exit, the VFP state is
      returned to the host.  When disabling access to floating point
      instructions, we also mask FPEXC_EN in order to avoid the guest
      receiving Undefined instruction exceptions before we have a chance to
      switch back the floating point state.  We are reusing vfp_hard_struct,
      so we depend on VFPv3 being enabled in the host kernel, if not, we still
      trap cp10 and cp11 in order to inject an undefined instruction exception
      whenever the guest tries to use VFP/NEON. VFP/NEON developed by
      Antionios Motakis and Rusty Russell.
      
      Aborts that are permission faults, and not stage-1 page table walk, do
      not report the faulting address in the HPFAR.  We have to resolve the
      IPA, and store it just like the HPFAR register on the VCPU struct. If
      the IPA cannot be resolved, it means another CPU is playing with the
      page tables, and we simply restart the guest.  This quirk was fixed by
      Marc Zyngier.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAntonios Motakis <a.motakis@virtualopensystems.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      f7ed45be
    • C
      KVM: ARM: Memory virtualization setup · d5d8184d
      Christoffer Dall 提交于
      This commit introduces the framework for guest memory management
      through the use of 2nd stage translation. Each VM has a pointer
      to a level-1 table (the pgd field in struct kvm_arch) which is
      used for the 2nd stage translations. Entries are added when handling
      guest faults (later patch) and the table itself can be allocated and
      freed through the following functions implemented in
      arch/arm/kvm/arm_mmu.c:
       - kvm_alloc_stage2_pgd(struct kvm *kvm);
       - kvm_free_stage2_pgd(struct kvm *kvm);
      
      Each entry in TLBs and caches are tagged with a VMID identifier in
      addition to ASIDs. The VMIDs are assigned consecutively to VMs in the
      order that VMs are executed, and caches and tlbs are invalidated when
      the VMID space has been used to allow for more than 255 simultaenously
      running guests.
      
      The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
      freed in kvm_arch_destroy_vm(). Both functions are called from the main
      KVM code.
      
      We pre-allocate page table memory to be able to synchronize using a
      spinlock and be called under rcu_read_lock from the MMU notifiers.  We
      steal the mmu_memory_cache implementation from x86 and adapt for our
      specific usage.
      
      We support MMU notifiers (thanks to Marc Zyngier) through
      kvm_unmap_hva and kvm_set_spte_hva.
      
      Finally, define kvm_phys_addr_ioremap() to map a device at a guest IPA,
      which is used by VGIC support to map the virtual CPU interface registers
      to the guest. This support is added by Marc Zyngier.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      d5d8184d
    • C
      KVM: ARM: Hypervisor initialization · 342cd0ab
      Christoffer Dall 提交于
      Sets up KVM code to handle all exceptions taken to Hyp mode.
      
      When the kernel is booted in Hyp mode, calling an hvc instruction with r0
      pointing to the new vectors, the HVBAR is changed to the the vector pointers.
      This allows subsystems (like KVM here) to execute code in Hyp-mode with the
      MMU disabled.
      
      We initialize other Hyp-mode registers and enables the MMU for Hyp-mode from
      the id-mapped hyp initialization code. Afterwards, the HVBAR is changed to
      point to KVM Hyp vectors used to catch guest faults and to switch to Hyp mode
      to perform a world-switch into a KVM guest.
      
      Also provides memory mapping code to map required code pages, data structures,
      and I/O regions  accessed in Hyp mode at the same virtual address as the host
      kernel virtual addresses, but which conforms to the architectural requirements
      for translations in Hyp mode. This interface is added in arch/arm/kvm/arm_mmu.c
      and comprises:
       - create_hyp_mappings(from, to);
       - create_hyp_io_mappings(from, to, phys_addr);
       - free_hyp_pmds();
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      342cd0ab