1. 17 Apr, 2013 1 commit
  2. 22 Mar, 2013 1 commit
    • Bharat Bhushan's avatar
      KVM: PPC: Added one_reg interface for timer registers · 78accda4
      Bharat Bhushan authored
      
      
      If userspace wants to change some specific bits of TSR
      (timer status register) then it uses GET/SET_SREGS ioctl interface.
      So the steps will be:
            i)   user-space will make get ioctl,
            ii)  change TSR in userspace
            iii) then make set ioctl.
      It can happen that TSR gets changed by kernel after step i) and
      before step iii).
      
      To avoid this we have added below one_reg ioctls for oring and clearing
      specific bits in TSR. This patch adds one registerface for:
           1) setting specific bit in TSR (timer status register)
           2) clearing specific bit in TSR (timer status register)
           3) setting/getting the TCR register. There are cases where we want to only
              change TCR and not TSR. Although we can uses SREGS without
              KVM_SREGS_E_UPDATE_TSR flag but I think one reg is better. I am open
              if someone feels we should use SREGS only here.
           4) getting/setting TSR register
      
      Signed-off-by: default avatarBharat Bhushan <bharat.bhushan@freescale.com>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      78accda4
  3. 10 Jan, 2013 1 commit
  4. 06 Dec, 2012 2 commits
    • Mihai Caraman's avatar
      KVM: PPC: booke: Get/set guest EPCR register using ONE_REG interface · 352df1de
      Mihai Caraman authored
      
      
      Implement ONE_REG interface for EPCR register adding KVM_REG_PPC_EPCR to
      the list of ONE_REG PPC supported registers.
      
      Signed-off-by: default avatarMihai Caraman <mihai.caraman@freescale.com>
      [agraf: remove HV dependency, use get/put_user]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      352df1de
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Provide a method for userspace to read and write the HPT · a2932923
      Paul Mackerras authored
      
      
      A new ioctl, KVM_PPC_GET_HTAB_FD, returns a file descriptor.  Reads on
      this fd return the contents of the HPT (hashed page table), writes
      create and/or remove entries in the HPT.  There is a new capability,
      KVM_CAP_PPC_HTAB_FD, to indicate the presence of the ioctl.  The ioctl
      takes an argument structure with the index of the first HPT entry to
      read out and a set of flags.  The flags indicate whether the user is
      intending to read or write the HPT, and whether to return all entries
      or only the "bolted" entries (those with the bolted bit, 0x10, set in
      the first doubleword).
      
      This is intended for use in implementing qemu's savevm/loadvm and for
      live migration.  Therefore, on reads, the first pass returns information
      about all HPTEs (or all bolted HPTEs).  When the first pass reaches the
      end of the HPT, it returns from the read.  Subsequent reads only return
      information about HPTEs that have changed since they were last read.
      A read that finds no changed HPTEs in the HPT following where the last
      read finished will return 0 bytes.
      
      The format of the data provides a simple run-length compression of the
      invalid entries.  Each block of data starts with a header that indicates
      the index (position in the HPT, which is just an array), the number of
      valid entries starting at that index (may be zero), and the number of
      invalid entries following those valid entries.  The valid entries, 16
      bytes each, follow the header.  The invalid entries are not explicitly
      represented.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      [agraf: fix documentation]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      a2932923
  5. 09 Oct, 2012 1 commit
  6. 05 Oct, 2012 4 commits
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Provide a way for userspace to get/set per-vCPU areas · 55b665b0
      Paul Mackerras authored
      
      
      The PAPR paravirtualization interface lets guests register three
      different types of per-vCPU buffer areas in its memory for communication
      with the hypervisor.  These are called virtual processor areas (VPAs).
      Currently the hypercalls to register and unregister VPAs are handled
      by KVM in the kernel, and userspace has no way to know about or save
      and restore these registrations across a migration.
      
      This adds "register" codes for these three areas that userspace can
      use with the KVM_GET/SET_ONE_REG ioctls to see what addresses have
      been registered, and to register or unregister them.  This will be
      needed for guest hibernation and migration, and is also needed so
      that userspace can unregister them on reset (otherwise we corrupt
      guest memory after reboot by writing to the VPAs registered by the
      previous kernel).
      
      The "register" for the VPA is a 64-bit value containing the address,
      since the length of the VPA is fixed.  The "registers" for the SLB
      shadow buffer and dispatch trace log (DTL) are 128 bits long,
      consisting of the guest physical address in the high (first) 64 bits
      and the length in the low 64 bits.
      
      This also fixes a bug where we were calling init_vpa unconditionally,
      leading to an oops when unregistering the VPA.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      55b665b0
    • Paul Mackerras's avatar
      KVM: PPC: Book3S: Get/set guest FP regs using the GET/SET_ONE_REG interface · a8bd19ef
      Paul Mackerras authored
      
      
      This enables userspace to get and set all the guest floating-point
      state using the KVM_[GS]ET_ONE_REG ioctls.  The floating-point state
      includes all of the traditional floating-point registers and the
      FPSCR (floating point status/control register), all the VMX/Altivec
      vector registers and the VSCR (vector status/control register), and
      on POWER7, the vector-scalar registers (note that each FP register
      is the high-order half of the corresponding VSR).
      
      Most of these are implemented in common Book 3S code, except for VSX
      on POWER7.  Because HV and PR differ in how they store the FP and VSX
      registers on POWER7, the code for these cases is not common.  On POWER7,
      the FP registers are the upper halves of the VSX registers vsr0 - vsr31.
      PR KVM stores vsr0 - vsr31 in two halves, with the upper halves in the
      arch.fpr[] array and the lower halves in the arch.vsr[] array, whereas
      HV KVM on POWER7 stores the whole VSX register in arch.vsr[].
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      [agraf: fix whitespace, vsx compilation]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      a8bd19ef
    • Paul Mackerras's avatar
      KVM: PPC: Book3S: Get/set guest SPRs using the GET/SET_ONE_REG interface · a136a8bd
      Paul Mackerras authored
      
      
      This enables userspace to get and set various SPRs (special-purpose
      registers) using the KVM_[GS]ET_ONE_REG ioctls.  With this, userspace
      can get and set all the SPRs that are part of the guest state, either
      through the KVM_[GS]ET_REGS ioctls, the KVM_[GS]ET_SREGS ioctls, or
      the KVM_[GS]ET_ONE_REG ioctls.
      
      The SPRs that are added here are:
      
      - DABR:  Data address breakpoint register
      - DSCR:  Data stream control register
      - PURR:  Processor utilization of resources register
      - SPURR: Scaled PURR
      - DAR:   Data address register
      - DSISR: Data storage interrupt status register
      - AMR:   Authority mask register
      - UAMOR: User authority mask override register
      - MMCR0, MMCR1, MMCRA: Performance monitor unit control registers
      - PMC1..PMC8: Performance monitor unit counter registers
      
      In order to reduce code duplication between PR and HV KVM code, this
      moves the kvm_vcpu_ioctl_[gs]et_one_reg functions into book3s.c and
      centralizes the copying between user and kernel space there.  The
      registers that are handled differently between PR and HV, and those
      that exist only in one flavor, are handled in kvmppc_[gs]et_one_reg()
      functions that are specific to each flavor.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      [agraf: minimal style fixes]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      a136a8bd
    • Bharat Bhushan's avatar
      booke: Added ONE_REG interface for IAC/DAC debug registers · 6df8d3fc
      Bharat Bhushan authored
      
      
      IAC/DAC are defined as 32 bit while they are 64 bit wide. So ONE_REG
      interface is added to set/get them.
      
      Signed-off-by: default avatarBharat Bhushan <bharat.bhushan@freescale.com>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      6df8d3fc
  7. 08 Apr, 2012 1 commit
  8. 05 Mar, 2012 4 commits
  9. 27 Dec, 2011 1 commit
  10. 17 Nov, 2011 1 commit
  11. 25 Sep, 2011 2 commits
    • Alexander Graf's avatar
      KVM: PPC: Add sanity checking to vcpu_run · af8f38b3
      Alexander Graf authored
      
      
      There are multiple features in PowerPC KVM that can now be enabled
      depending on the user's wishes. Some of the combinations don't make
      sense or don't work though.
      
      So this patch adds a way to check if the executing environment would
      actually be able to run the guest properly. It also adds sanity
      checks if PVR is set (should always be true given the current code
      flow), if PAPR is only used with book3s_64 where it works and that
      HV KVM is only used in PAPR mode.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      af8f38b3
    • Alexander Graf's avatar
      KVM: PPC: Add support for explicit HIOR setting · a15bd354
      Alexander Graf authored
      
      
      Until now, we always set HIOR based on the PVR, but this is just wrong.
      Instead, we should be setting HIOR explicitly, so user space can decide
      what the initial HIOR value is - just like on real hardware.
      
      We keep the old PVR based way around for backwards compatibility, but
      once user space uses the SREGS based method, we drop the PVR logic.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      a15bd354
  12. 12 Jul, 2011 3 commits
    • Paul Mackerras's avatar
      KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests · aa04b4cc
      Paul Mackerras authored
      
      
      This adds infrastructure which will be needed to allow book3s_hv KVM to
      run on older POWER processors, including PPC970, which don't support
      the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
      Offset (RMO) facility.  These processors require a physically
      contiguous, aligned area of memory for each guest.  When the guest does
      an access in real mode (MMU off), the address is compared against a
      limit value, and if it is lower, the address is ORed with an offset
      value (from the Real Mode Offset Register (RMOR)) and the result becomes
      the real address for the access.  The size of the RMA has to be one of
      a set of supported values, which usually includes 64MB, 128MB, 256MB
      and some larger powers of 2.
      
      Since we are unlikely to be able to allocate 64MB or more of physically
      contiguous memory after the kernel has been running for a while, we
      allocate a pool of RMAs at boot time using the bootmem allocator.  The
      size and number of the RMAs can be set using the kvm_rma_size=xx and
      kvm_rma_count=xx kernel command line options.
      
      KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
      of the pool of preallocated RMAs.  The capability value is 1 if the
      processor can use an RMA but doesn't require one (because it supports
      the VRMA facility), or 2 if the processor requires an RMA for each guest.
      
      This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
      pool and returns a file descriptor which can be used to map the RMA.  It
      also returns the size of the RMA in the argument structure.
      
      Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
      ioctl calls from userspace.  To cope with this, we now preallocate the
      kvm->arch.ram_pginfo array when the VM is created with a size sufficient
      for up to 64GB of guest memory.  Subsequently we will get rid of this
      array and use memory associated with each memslot instead.
      
      This moves most of the code that translates the user addresses into
      host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
      to kvmppc_core_prepare_memory_region.  Also, instead of having to look
      up the VMA for each page in order to check the page size, we now check
      that the pages we get are compound pages of 16MB.  However, if we are
      adding memory that is mapped to an RMA, we don't bother with calling
      get_user_pages_fast and instead just offset from the base pfn for the
      RMA.
      
      Typically the RMA gets added after vcpus are created, which makes it
      inconvenient to have the LPCR (logical partition control register) value
      in the vcpu->arch struct, since the LPCR controls whether the processor
      uses RMA or VRMA for the guest.  This moves the LPCR value into the
      kvm->arch struct and arranges for the MER (mediated external request)
      bit, which is the only bit that varies between vcpus, to be set in
      assembly code when going into the guest if there is a pending external
      interrupt request.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      aa04b4cc
    • Paul Mackerras's avatar
      KVM: PPC: Allow book3s_hv guests to use SMT processor modes · 371fefd6
      Paul Mackerras authored
      
      
      This lifts the restriction that book3s_hv guests can only run one
      hardware thread per core, and allows them to use up to 4 threads
      per core on POWER7.  The host still has to run single-threaded.
      
      This capability is advertised to qemu through a new KVM_CAP_PPC_SMT
      capability.  The return value of the ioctl querying this capability
      is the number of vcpus per virtual CPU core (vcore), currently 4.
      
      To use this, the host kernel should be booted with all threads
      active, and then all the secondary threads should be offlined.
      This will put the secondary threads into nap mode.  KVM will then
      wake them from nap mode and use them for running guest code (while
      they are still offline).  To wake the secondary threads, we send
      them an IPI using a new xics_wake_cpu() function, implemented in
      arch/powerpc/sysdev/xics/icp-native.c.  In other words, at this stage
      we assume that the platform has a XICS interrupt controller and
      we are using icp-native.c to drive it.  Since the woken thread will
      need to acknowledge and clear the IPI, we also export the base
      physical address of the XICS registers using kvmppc_set_xics_phys()
      for use in the low-level KVM book3s code.
      
      When a vcpu is created, it is assigned to a virtual CPU core.
      The vcore number is obtained by dividing the vcpu number by the
      number of threads per core in the host.  This number is exported
      to userspace via the KVM_CAP_PPC_SMT capability.  If qemu wishes
      to run the guest in single-threaded mode, it should make all vcpu
      numbers be multiples of the number of threads per core.
      
      We distinguish three states of a vcpu: runnable (i.e., ready to execute
      the guest), blocked (that is, idle), and busy in host.  We currently
      implement a policy that the vcore can run only when all its threads
      are runnable or blocked.  This way, if a vcpu needs to execute elsewhere
      in the kernel or in qemu, it can do so without being starved of CPU
      by the other vcpus.
      
      When a vcore starts to run, it executes in the context of one of the
      vcpu threads.  The other vcpu threads all go to sleep and stay asleep
      until something happens requiring the vcpu thread to return to qemu,
      or to wake up to run the vcore (this can happen when another vcpu
      thread goes from busy in host state to blocked).
      
      It can happen that a vcpu goes from blocked to runnable state (e.g.
      because of an interrupt), and the vcore it belongs to is already
      running.  In that case it can start to run immediately as long as
      the none of the vcpus in the vcore have started to exit the guest.
      We send the next free thread in the vcore an IPI to get it to start
      to execute the guest.  It synchronizes with the other threads via
      the vcore->entry_exit_count field to make sure that it doesn't go
      into the guest if the other vcpus are exiting by the time that it
      is ready to actually enter the guest.
      
      Note that there is no fixed relationship between the hardware thread
      number and the vcpu number.  Hardware threads are assigned to vcpus
      as they become runnable, so we will always use the lower-numbered
      hardware threads in preference to higher-numbered threads if not all
      the vcpus in the vcore are runnable, regardless of which vcpus are
      runnable.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      371fefd6
    • David Gibson's avatar
      KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode · 54738c09
      David Gibson authored
      
      
      This improves I/O performance for guests using the PAPR
      paravirtualization interface by making the H_PUT_TCE hcall faster, by
      implementing it in real mode.  H_PUT_TCE is used for updating virtual
      IOMMU tables, and is used both for virtual I/O and for real I/O in the
      PAPR interface.
      
      Since this moves the IOMMU tables into the kernel, we define a new
      KVM_CREATE_SPAPR_TCE ioctl to allow qemu to create the tables.  The
      ioctl returns a file descriptor which can be used to mmap the newly
      created table.  The qemu driver models use them in the same way as
      userspace managed tables, but they can be updated directly by the
      guest with a real-mode H_PUT_TCE implementation, reducing the number
      of host/guest context switches during guest IO.
      
      There are certain circumstances where it is useful for userland qemu
      to write to the TCE table even if the kernel H_PUT_TCE path is used
      most of the time.  Specifically, allowing this will avoid awkwardness
      when we need to reset the table.  More importantly, we will in the
      future need to write the table in order to restore its state after a
      checkpoint resume or migration.
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      54738c09
  13. 22 May, 2011 1 commit
  14. 24 Oct, 2010 1 commit
    • Alexander Graf's avatar
      KVM: PPC: Implement Level interrupts on Book3S · 17bd1580
      Alexander Graf authored
      
      
      The current interrupt logic is just completely broken. We get a notification
      from user space, telling us that an interrupt is there. But then user space
      expects us that we just acknowledge an interrupt once we deliver it to the
      guest.
      
      This is not how real hardware works though. On real hardware, the interrupt
      controller pulls the external interrupt line until it gets notified that the
      interrupt was received.
      
      So in reality we have two events: pulling and letting go of the interrupt line.
      
      To maintain backwards compatibility, I added a new request for the pulling
      part. The letting go part was implemented earlier already.
      
      With this in place, we can now finally start guests that do not randomly stall
      and stop to work at random times.
      
      This patch implements above logic for Book3S.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      17bd1580
  15. 17 May, 2010 1 commit
  16. 25 Apr, 2010 1 commit
  17. 08 Dec, 2009 1 commit
  18. 05 Nov, 2009 1 commit
    • Alexander Graf's avatar
      Pass PVR in sregs · ec3c11aa
      Alexander Graf authored
      
      
      Right now sregs is unused on PPC, so we can use it for initialization
      of the CPU.
      
      KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
      and take the PVR from userspace that tells us what kind of CPU we are supposed
      to virtualize, because we support Book3s_32 and Book3s_64 guests.
      
      In order to get that information, we use the sregs ioctl, because we don't
      want to reset the guest CPU on every normal register set.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ec3c11aa
  19. 24 Mar, 2009 1 commit
    • Jan Kiszka's avatar
      KVM: New guest debug interface · d0bfb940
      Jan Kiszka authored
      
      
      This rips out the support for KVM_DEBUG_GUEST and introduces a new IOCTL
      instead: KVM_SET_GUEST_DEBUG. The IOCTL payload consists of a generic
      part, controlling the "main switch" and the single-step feature. The
      arch specific part adds an x86 interface for intercepting both types of
      debug exceptions separately and re-injecting them when the host was not
      interested. Moveover, the foundation for guest debugging via debug
      registers is layed.
      
      To signal breakpoint events properly back to userland, an arch-specific
      data block is now returned along KVM_EXIT_DEBUG. For x86, the arch block
      contains the PC, the debug exception, and relevant debug registers to
      tell debug events properly apart.
      
      The availability of this new interface is signaled by
      KVM_CAP_SET_GUEST_DEBUG. Empty stubs for not yet supported archs are
      provided.
      
      Note that both SVM and VTX are supported, but only the latter was tested
      yet. Based on the experience with all those VTX corner case, I would be
      fairly surprised if SVM will work out of the box.
      
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      d0bfb940
  20. 22 Feb, 2009 1 commit
    • Kumar Gala's avatar
      powerpc: Fix warnings from make headers_check · 812d904e
      Kumar Gala authored
      
      
      include/asm/bootx.h:12: include of <linux/types.h> is preferred over <asm/types.h>
      include/asm/bootx.h:57: found __[us]{8,16,32,64} type without #include <linux/types.h>
      include/asm/elf.h:5: include of <linux/types.h> is preferred over <asm/types.h>
      include/asm/kvm.h:23: include of <linux/types.h> is preferred over <asm/types.h>
      include/asm/kvm.h:26: found __[us]{8,16,32,64} type without #include <linux/types.h>
      include/asm/ps3fb.h:33: found __[us]{8,16,32,64} type without #include <linux/types.h>
      include/asm/spu_info.h:27: found __[us]{8,16,32,64} type without #include <linux/types.h>
      include/asm/swab.h:11: include of <linux/types.h> is preferred over <asm/types.h>
      
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      812d904e
  21. 01 Feb, 2009 1 commit
  22. 04 Aug, 2008 1 commit
  23. 27 Apr, 2008 1 commit
  24. 02 Apr, 2008 1 commit
    • Christian Borntraeger's avatar
      kvm: provide kvm.h for all architecture: fixes headers_install · dd135ebb
      Christian Borntraeger authored
      Currently include/linux/kvm.h is not considered by make headers_install,
      because Kbuild cannot handle " unifdef-$(CONFIG_FOO) += foo.h.  This problem
      was introduced by
      
      commit fb56dbb3
      
      
      Author: Avi Kivity <avi@qumranet.com>
      Date:   Sun Dec 2 10:50:06 2007 +0200
      
          KVM: Export include/linux/kvm.h only if $ARCH actually supports KVM
      
          Currently, make headers_check barfs due to <asm/kvm.h>, which <linux/kvm.h>
          includes, not existing.  Rather than add a zillion <asm/kvm.h>s, export kvm.
          only if the arch actually supports it.
      
      Signed-off-by: default avatarAvi Kivity <avi@qumranet.com>
      
      which makes this an 2.6.25 regression.
      
      One way of solving the issue is to enhance Kbuild, but Avi and David conviced
      me, that changing headers_install is not the way to go.  This patch changes
      the definition for linux/kvm.h to unifdef-y.
      
      If  unifdef-y is used for linux/kvm.h "make headers_check" will fail on all
      architectures without asm/kvm.h.  Therefore, this patch also provides
      asm/kvm.h on all architectures.
      
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: default avatarAvi Kivity <avi@qumranet.com>
      Cc: Sam Ravnborg <sam@ravnborg.org
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd135ebb