1. 29 2月, 2016 1 次提交
    • S
      KVM: PPC: Book3S HV: Send IPI to host core to wake VCPU · e17769eb
      Suresh E. Warrier 提交于
      This patch adds support to real-mode KVM to search for a core
      running in the host partition and send it an IPI message with
      VCPU to be woken. This avoids having to switch to the host
      partition to complete an H_IPI hypercall when the VCPU which
      is the target of the the H_IPI is not loaded (is not running
      in the guest).
      
      The patch also includes the support in the IPI handler running
      in the host to do the wakeup by calling kvmppc_xics_ipi_action
      for the PPC_MSG_RM_HOST_ACTION message.
      
      When a guest is being destroyed, we need to ensure that there
      are no pending IPIs waiting to wake up a VCPU before we free
      the VCPUs of the guest. This is accomplished by:
      - Forces a PPC_MSG_CALL_FUNCTION IPI to be completed by all CPUs
        before freeing any VCPUs in kvm_arch_destroy_vm().
      - Any PPC_MSG_RM_HOST_ACTION messages must be executed first
        before any other PPC_MSG_CALL_FUNCTION messages.
      Signed-off-by: NSuresh Warrier <warrier@linux.vnet.ibm.com>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e17769eb
  2. 16 2月, 2016 1 次提交
    • A
      KVM: PPC: Add support for multiple-TCE hcalls · d3695aa4
      Alexey Kardashevskiy 提交于
      This adds real and virtual mode handlers for the H_PUT_TCE_INDIRECT and
      H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO
      devices or emulated PCI. These calls allow adding multiple entries
      (up to 512) into the TCE table in one call which saves time on
      transition between kernel and user space.
      
      The current implementation of kvmppc_h_stuff_tce() allows it to be
      executed in both real and virtual modes so there is one helper.
      The kvmppc_rm_h_put_tce_indirect() needs to translate the guest address
      to the host address and since the translation is different, there are
      2 helpers - one for each mode.
      
      This implements the KVM_CAP_PPC_MULTITCE capability. When present,
      the kernel will try handling H_PUT_TCE_INDIRECT and H_STUFF_TCE if these
      are enabled by the userspace via KVM_CAP_PPC_ENABLE_HCALL.
      If they can not be handled by the kernel, they are passed on to
      the user space. The user space still has to have an implementation
      for these.
      
      Both HV and PR-syle KVM are supported.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d3695aa4
  3. 14 1月, 2016 1 次提交
  4. 21 10月, 2015 1 次提交
  5. 22 8月, 2015 1 次提交
    • T
      KVM: PPC: Fix warnings from sparse · 5358a963
      Thomas Huth 提交于
      When compiling the KVM code for POWER with "make C=1", sparse
      complains about functions missing proper prototypes and a 64-bit
      constant missing the ULL prefix. Let's fix this by making the
      functions static or by including the proper header with the
      prototypes, and by appending a ULL prefix to the constant
      PPC_MPPE_ADDRESS_MASK.
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      5358a963
  6. 28 5月, 2015 1 次提交
  7. 26 5月, 2015 1 次提交
  8. 07 5月, 2015 1 次提交
  9. 21 4月, 2015 1 次提交
    • M
      KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation. · e928e9cb
      Michael Ellerman 提交于
      Some PowerNV systems include a hardware random-number generator.
      This HWRNG is present on POWER7+ and POWER8 chips and is capable of
      generating one 64-bit random number every microsecond.  The random
      numbers are produced by sampling a set of 64 unstable high-frequency
      oscillators and are almost completely entropic.
      
      PAPR defines an H_RANDOM hypercall which guests can use to obtain one
      64-bit random sample from the HWRNG.  This adds a real-mode
      implementation of the H_RANDOM hypercall.  This hypercall was
      implemented in real mode because the latency of reading the HWRNG is
      generally small compared to the latency of a guest exit and entry for
      all the threads in the same virtual core.
      
      Userspace can detect the presence of the HWRNG and the H_RANDOM
      implementation by querying the KVM_CAP_PPC_HWRNG capability.  The
      H_RANDOM hypercall implementation will only be invoked when the guest
      does an H_RANDOM hypercall if userspace first enables the in-kernel
      H_RANDOM implementation using the KVM_CAP_PPC_ENABLE_HCALL capability.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      e928e9cb
  10. 27 3月, 2015 1 次提交
  11. 24 3月, 2015 1 次提交
    • D
      powerpc: Cleanup KVM emulated load/store endian handling · d078eed3
      David Gibson 提交于
      Sometimes the KVM code on powerpc needs to emulate load or store
      instructions from the guest, which can include both normal and byte
      reversed forms.
      
      We currently (AFAICT) handle this correctly, but some variable names are
      very misleading.  In particular we use "is_bigendian" in several places to
      actually mean "is the IO the same endian as the host", but we now support
      little-endian powerpc hosts.  This also ties into the misleadingly named
      ld_le*() and st_le*() functions, which in fact always byteswap, even on
      an LE host.
      
      This patch cleans this up by renaming to more accurate "host_swabbed", and
      uses the generic swab*() functions instead of the powerpc specific and
      misleadingly named ld_le*() and st_le*() functions.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d078eed3
  12. 23 1月, 2015 1 次提交
  13. 17 12月, 2014 1 次提交
    • P
      KVM: PPC: Book3S HV: Remove code for PPC970 processors · c17b98cf
      Paul Mackerras 提交于
      This removes the code that was added to enable HV KVM to work
      on PPC970 processors.  The PPC970 is an old CPU that doesn't
      support virtualizing guest memory.  Removing PPC970 support also
      lets us remove the code for allocating and managing contiguous
      real-mode areas, the code for the !kvm->arch.using_mmu_notifiers
      case, the code for pinning pages of guest memory when first
      accessed and keeping track of which pages have been pinned, and
      the code for handling H_ENTER hypercalls in virtual mode.
      
      Book3S HV KVM is now supported only on POWER7 and POWER8 processors.
      The KVM_CAP_PPC_RMA capability now always returns 0.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      c17b98cf
  14. 22 9月, 2014 4 次提交
  15. 29 8月, 2014 2 次提交
  16. 22 8月, 2014 1 次提交
  17. 05 8月, 2014 1 次提交
    • P
      KVM: PPC: drop duplicate tracepoint · 478d6686
      Paolo Bonzini 提交于
      Commit 29577fc0 ("KVM: PPC: HV: Remove generic instruction emulation")
      caused a build failure with allyesconfig:
      
      arch/powerpc/kvm/kvm-pr.o:(__tracepoints+0xa8): multiple definition of `__tracepoint_kvm_ppc_instr'
      arch/powerpc/kvm/kvm.o:(__tracepoints+0x1c0): first defined here
      
      due to a duplicate definition of the tracepoint in trace.h and
      trace_pr.h.  Because the tracepoint is still used by Book3S HV
      code, and because the PR code does include trace.h, just remove
      the duplicate definition from trace_pr.h, and export it from
      kvm.o.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      478d6686
  18. 29 7月, 2014 2 次提交
  19. 28 7月, 2014 11 次提交
    • A
      KVM: PPC: Handle magic page in kvmppc_ld/st · c12fb43c
      Alexander Graf 提交于
      We use kvmppc_ld and kvmppc_st to emulate load/store instructions that may as
      well access the magic page. Special case it out so that we can properly access
      it.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      c12fb43c
    • A
      KVM: PPC: Use kvm_read_guest in kvmppc_ld · c45c5514
      Alexander Graf 提交于
      We have a nice and handy helper to read from guest physical address space,
      so we should make use of it in kvmppc_ld as we already do for its counterpart
      in kvmppc_st.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      c45c5514
    • A
      KVM: PPC: Remove kvmppc_bad_hva() · 9897e88a
      Alexander Graf 提交于
      We have a proper define for invalid HVA numbers. Use those instead of the
      ppc specific kvmppc_bad_hva().
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      9897e88a
    • A
      KVM: PPC: Move kvmppc_ld/st to common code · 35c4a733
      Alexander Graf 提交于
      We have enough common infrastructure now to resolve GVA->GPA mappings at
      runtime. With this we can move our book3s specific helpers to load / store
      in guest virtual address space to common code as well.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      35c4a733
    • A
      KVM: PPC: Book3S: Provide different CAPs based on HV or PR mode · 7a58777a
      Alexander Graf 提交于
      With Book3S KVM we can create both PR and HV VMs in parallel on the same
      machine. That gives us new challenges on the CAPs we return - both have
      different capabilities.
      
      When we get asked about CAPs on the kvm fd, there's nothing we can do. We
      can try to be smart and assume we're running HV if HV is available, PR
      otherwise. However with the newly added VM CHECK_EXTENSION we can now ask
      for capabilities directly on a VM which knows whether it's PR or HV.
      
      With this patch I can successfully expose KVM PVINFO data to user space
      in the PR case, fixing magic page mapping for PAPR guests.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      7a58777a
    • A
      KVM: Rename and add argument to check_extension · 784aa3d7
      Alexander Graf 提交于
      In preparation to make the check_extension function available to VM scope
      we add a struct kvm * argument to the function header and rename the function
      accordingly. It will still be called from the /dev/kvm fd, but with a NULL
      argument for struct kvm *.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      784aa3d7
    • A
      KVM: PPC: Remove 440 support · b2677b8d
      Alexander Graf 提交于
      The 440 target hasn't been properly functioning for a few releases and
      before I was the only one who fixes a very serious bug that indicates to
      me that nobody used it before either.
      
      Furthermore KVM on 440 is slow to the extent of unusable.
      
      We don't have to carry along completely unused code. Remove 440 and give
      us one less thing to worry about.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      b2677b8d
    • M
      KVM: PPC: Allow kvmppc_get_last_inst() to fail · 51f04726
      Mihai Caraman 提交于
      On book3e, guest last instruction is read on the exit path using load
      external pid (lwepx) dedicated instruction. This load operation may fail
      due to TLB eviction and execute-but-not-read entries.
      
      This patch lay down the path for an alternative solution to read the guest
      last instruction, by allowing kvmppc_get_lat_inst() function to fail.
      Architecture specific implmentations of kvmppc_load_last_inst() may read
      last guest instruction and instruct the emulation layer to re-execute the
      guest in case of failure.
      
      Make kvmppc_get_last_inst() definition common between architectures.
      Signed-off-by: NMihai Caraman <mihai.caraman@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      51f04726
    • A
      KVM: PPC: Book3S: Make magic page properly 4k mappable · 89b68c96
      Alexander Graf 提交于
      The magic page is defined as a 4k page of per-vCPU data that is shared
      between the guest and the host to accelerate accesses to privileged
      registers.
      
      However, when the host is using 64k page size granularity we weren't quite
      as strict about that rule anymore. Instead, we partially treated all of the
      upper 64k as magic page and mapped only the uppermost 4k with the actual
      magic contents.
      
      This works well enough for Linux which doesn't use any memory in kernel
      space in the upper 64k, but Mac OS X got upset. So this patch makes magic
      page actually stay in a 4k range even on 64k page size hosts.
      
      This patch fixes magic page usage with Mac OS X (using MOL) on 64k PAGE_SIZE
      hosts for me.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      89b68c96
    • P
      KVM: PPC: Book3S: Allow only implemented hcalls to be enabled or disabled · ae2113a4
      Paul Mackerras 提交于
      This adds code to check that when the KVM_CAP_PPC_ENABLE_HCALL
      capability is used to enable or disable in-kernel handling of an
      hcall, that the hcall is actually implemented by the kernel.
      If not an EINVAL error is returned.
      
      This also checks the default-enabled list of hcalls and prints a
      warning if any hcall there is not actually implemented.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      ae2113a4
    • P
      KVM: PPC: Book3S: Controls for in-kernel sPAPR hypercall handling · 699a0ea0
      Paul Mackerras 提交于
      This provides a way for userspace controls which sPAPR hcalls get
      handled in the kernel.  Each hcall can be individually enabled or
      disabled for in-kernel handling, except for H_RTAS.  The exception
      for H_RTAS is because userspace can already control whether
      individual RTAS functions are handled in-kernel or not via the
      KVM_PPC_RTAS_DEFINE_TOKEN ioctl, and because the numeric value for
      H_RTAS is out of the normal sequence of hcall numbers.
      
      Hcalls are enabled or disabled using the KVM_ENABLE_CAP ioctl for the
      KVM_CAP_PPC_ENABLE_HCALL capability on the file descriptor for the VM.
      The args field of the struct kvm_enable_cap specifies the hcall number
      in args[0] and the enable/disable flag in args[1]; 0 means disable
      in-kernel handling (so that the hcall will always cause an exit to
      userspace) and 1 means enable.  Enabling or disabling in-kernel
      handling of an hcall is effective across the whole VM.
      
      The ability for KVM_ENABLE_CAP to be used on a VM file descriptor
      on PowerPC is new, added by this commit.  The KVM_CAP_ENABLE_CAP_VM
      capability advertises that this ability exists.
      
      When a VM is created, an initial set of hcalls are enabled for
      in-kernel handling.  The set that is enabled is the set that have
      an in-kernel implementation at this point.  Any new hcall
      implementations from this point onwards should not be added to the
      default set without a good reason.
      
      No distinction is made between real-mode and virtual-mode hcall
      implementations; the one setting controls them both.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      699a0ea0
  20. 30 5月, 2014 4 次提交
    • A
      KVM: PPC: Add CAP to indicate hcall fixes · f2e91042
      Alexander Graf 提交于
      We worked around some nasty KVM magic page hcall breakages:
      
        1) NX bit not honored, so ignore NX when we detect it
        2) LE guests swizzle hypercall instruction
      
      Without these fixes in place, there's no way it would make sense to expose kvm
      hypercalls to a guest. Chances are immensely high it would trip over and break.
      
      So add a new CAP that gives user space a hint that we have workarounds for the
      bugs above in place. It can use those as hint to disable PV hypercalls when
      the guest CPU is anything POWER7 or higher and the host does not have fixes
      in place.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f2e91042
    • A
      KVM: PPC: Disable NX for old magic page using guests · f3383cf8
      Alexander Graf 提交于
      Old guests try to use the magic page, but map their trampoline code inside
      of an NX region.
      
      Since we can't fix those old kernels, try to detect whether the guest is sane
      or not. If not, just disable NX functionality in KVM so that old guests at
      least work at all. For newer guests, add a bit that we can set to keep NX
      functionality available.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f3383cf8
    • A
      KVM: PPC: Make shared struct aka magic page guest endian · 5deb8e7a
      Alexander Graf 提交于
      The shared (magic) page is a data structure that contains often used
      supervisor privileged SPRs accessible via memory to the user to reduce
      the number of exits we have to take to read/write them.
      
      When we actually share this structure with the guest we have to maintain
      it in guest endianness, because some of the patch tricks only work with
      native endian load/store operations.
      
      Since we only share the structure with either host or guest in little
      endian on book3s_64 pr mode, we don't have to worry about booke or book3s hv.
      
      For booke, the shared struct stays big endian. For book3s_64 hv we maintain
      the struct in host native endian, since it never gets shared with the guest.
      
      For book3s_64 pr we introduce a variable that tells us which endianness the
      shared struct is in and route every access to it through helper inline
      functions that evaluate this variable.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      5deb8e7a
    • A
      KVM: PPC: PR: Fill pvinfo hcall instructions in big endian · 2743103f
      Alexander Graf 提交于
      We expose a blob of hypercall instructions to user space that it gives to
      the guest via device tree again. That blob should contain a stream of
      instructions necessary to do a hypercall in big endian, as it just gets
      passed into the guest and old guests use them straight away.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      2743103f
  21. 28 5月, 2014 1 次提交
  22. 27 1月, 2014 1 次提交
    • S
      kvm/ppc: IRQ disabling cleanup · 6c85f52b
      Scott Wood 提交于
      Simplify the handling of lazy EE by going directly from fully-enabled
      to hard-disabled.  This replaces the lazy_irq_pending() check
      (including its misplaced kvm_guest_exit() call).
      
      As suggested by Tiejun Chen, move the interrupt disabling into
      kvmppc_prepare_to_enter() rather than have each caller do it.  Also
      move the IRQ enabling on heavyweight exit into
      kvmppc_prepare_to_enter().
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      6c85f52b