1. 17 Dec, 2014 1 commit
  2. 15 Dec, 2014 8 commits
    • Suresh E. Warrier's avatar
      KVM: PPC: Book3S HV: Check wait conditions before sleeping in kvmppc_vcore_blocked · 1bc5d59c
      Suresh E. Warrier authored
      The kvmppc_vcore_blocked() code does not check for the wait condition
      after putting the process on the wait queue. This means that it is
      possible for an external interrupt to become pending, but the vcpu to
      remain asleep until the next decrementer interrupt.  The fix is to
      make one last check for pending exceptions and ceded state before
      calling schedule().
      Signed-off-by: default avatarSuresh Warrier <warrier@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      1bc5d59c
    • Cédric Le Goater's avatar
      KVM: PPC: Book3S HV: ptes are big endian · ffada016
      Cédric Le Goater authored
      When being restored from qemu, the kvm_get_htab_header are in native
      endian, but the ptes are big endian.
      
      This patch fixes restore on a KVM LE host. Qemu also needs a fix for
      this :
      
           http://lists.nongnu.org/archive/html/qemu-ppc/2014-11/msg00008.htmlSigned-off-by: default avatarCédric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      ffada016
    • Suresh E. Warrier's avatar
      KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI · 5b88cda6
      Suresh E. Warrier authored
      This fixes some inaccuracies in the state machine for the virtualized
      ICP when implementing the H_IPI hcall (Set_MFFR and related states):
      
      1. The old code wipes out any pending interrupts when the new MFRR is
         more favored than the CPPR but less favored than a pending
         interrupt (by always modifying xisr and the pending_pri). This can
         cause us to lose a pending external interrupt.
      
         The correct code here is to only modify the pending_pri and xisr in
         the ICP if the MFRR is equal to or more favored than the current
         pending pri (since in this case, it is guaranteed that that there
         cannot be a pending external interrupt). The code changes are
         required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
      
      2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
         for whether MFRR is being made less favored AND further if new MFFR
         is also less favored than the current CPPR, we check for any
         resends pending in the ICP. These checks look like they are
         designed to cover the case where if the MFRR is being made less
         favored, we opportunistically trigger a resend of any interrupts
         that had been previously rejected. Although, this is not a state
         described by PAPR, this is an action we actually need to do
         especially if the CPPR is already at 0xFF.  Because in this case,
         the resend bit will stay on until another ICP state change which
         may be a long time coming and the interrupt stays pending until
         then. The current code which checks for MFRR < CPPR is broken when
         CPPR is 0xFF since it will not get triggered in that case.
      
         Ideally, we would want to do a resend only if
      
         	prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
      
         where pending interrupt is the one that was rejected. But we don't
         have the priority of the pending interrupt state saved, so we
         simply trigger a resend whenever the MFRR is made less favored.
      
      3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
         virtual mode, we also need to save the ICP whose need_resend we
         reset since this does not need to be my ICP (vcpu->arch.icp) as is
         incorrectly assumed by the current code. A new field rm_resend_icp
         is added to the kvmppc_icp structure for this purpose.
      Signed-off-by: default avatarSuresh Warrier <warrier@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      5b88cda6
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Fix KSM memory corruption · b4a83900
      Paul Mackerras authored
      Testing with KSM active in the host showed occasional corruption of
      guest memory.  Typically a page that should have contained zeroes
      would contain values that look like the contents of a user process
      stack (values such as 0x0000_3fff_xxxx_xxx).
      
      Code inspection in kvmppc_h_protect revealed that there was a race
      condition with the possibility of granting write access to a page
      which is read-only in the host page tables.  The code attempts to keep
      the host mapping read-only if the host userspace PTE is read-only, but
      if that PTE had been temporarily made invalid for any reason, the
      read-only check would not trigger and the host HPTE could end up
      read-write.  Examination of the guest HPT in the failure situation
      revealed that there were indeed shared pages which should have been
      read-only that were mapped read-write.
      
      To close this race, we don't let a page go from being read-only to
      being read-write, as far as the real HPTE mapping the page is
      concerned (the guest view can go to read-write, but the actual mapping
      stays read-only).  When the guest tries to write to the page, we take
      an HDSI and let kvmppc_book3s_hv_page_fault take care of providing a
      writable HPTE for the page.
      
      This eliminates the occasional corruption of shared pages
      that was previously seen with KSM active.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      b4a83900
    • Mahesh Salgaonkar's avatar
      KVM: PPC: Book3S HV: Fix an issue where guest is paused on receiving HMI · dee6f24c
      Mahesh Salgaonkar authored
      When we get an HMI (hypervisor maintenance interrupt) while in a
      guest, we see that guest enters into paused state.  The reason is, in
      kvmppc_handle_exit_hv it falls through default path and returns to
      host instead of resuming guest.  This causes guest to enter into
      paused state.  HMI is a hypervisor only interrupt and it is safe to
      resume the guest since the host has handled it already.  This patch
      adds a switch case to resume the guest.
      
      Without this patch we see guest entering into paused state with following
      console messages:
      
      [ 3003.329351] Severe Hypervisor Maintenance interrupt [Recovered]
      [ 3003.329356]  Error detail: Timer facility experienced an error
      [ 3003.329359] 	HMER: 0840000000000000
      [ 3003.329360] 	TFMR: 4a12000980a84000
      [ 3003.329366] vcpu c0000007c35094c0 (40):
      [ 3003.329368] pc  = c0000000000c2ba0  msr = 8000000000009032  trap = e60
      [ 3003.329370] r 0 = c00000000021ddc0  r16 = 0000000000000046
      [ 3003.329372] r 1 = c00000007a02bbd0  r17 = 00003ffff27d5d98
      [ 3003.329375] r 2 = c0000000010980b8  r18 = 00001fffffc9a0b0
      [ 3003.329377] r 3 = c00000000142d6b8  r19 = c00000000142d6b8
      [ 3003.329379] r 4 = 0000000000000002  r20 = 0000000000000000
      [ 3003.329381] r 5 = c00000000524a110  r21 = 0000000000000000
      [ 3003.329383] r 6 = 0000000000000001  r22 = 0000000000000000
      [ 3003.329386] r 7 = 0000000000000000  r23 = c00000000524a110
      [ 3003.329388] r 8 = 0000000000000000  r24 = 0000000000000001
      [ 3003.329391] r 9 = 0000000000000001  r25 = c00000007c31da38
      [ 3003.329393] r10 = c0000000014280b8  r26 = 0000000000000002
      [ 3003.329395] r11 = 746f6f6c2f68656c  r27 = c00000000524a110
      [ 3003.329397] r12 = 0000000028004484  r28 = c00000007c31da38
      [ 3003.329399] r13 = c00000000fe01400  r29 = 0000000000000002
      [ 3003.329401] r14 = 0000000000000046  r30 = c000000003011e00
      [ 3003.329403] r15 = ffffffffffffffba  r31 = 0000000000000002
      [ 3003.329404] ctr = c00000000041a670  lr  = c000000000272520
      [ 3003.329405] srr0 = c00000000007e8d8 srr1 = 9000000000001002
      [ 3003.329406] sprg0 = 0000000000000000 sprg1 = c00000000fe01400
      [ 3003.329407] sprg2 = c00000000fe01400 sprg3 = 0000000000000005
      [ 3003.329408] cr = 48004482  xer = 2000000000000000  dsisr = 42000000
      [ 3003.329409] dar = 0000010015020048
      [ 3003.329410] fault dar = 0000010015020048 dsisr = 42000000
      [ 3003.329411] SLB (8 entries):
      [ 3003.329412]   ESID = c000000008000000 VSID = 40016e7779000510
      [ 3003.329413]   ESID = d000000008000001 VSID = 400142add1000510
      [ 3003.329414]   ESID = f000000008000004 VSID = 4000eb1a81000510
      [ 3003.329415]   ESID = 00001f000800000b VSID = 40004fda0a000d90
      [ 3003.329416]   ESID = 00003f000800000c VSID = 400039f536000d90
      [ 3003.329417]   ESID = 000000001800000d VSID = 0001251b35150d90
      [ 3003.329417]   ESID = 000001000800000e VSID = 4001e46090000d90
      [ 3003.329418]   ESID = d000080008000019 VSID = 40013d349c000400
      [ 3003.329419] lpcr = c048800001847001 sdr1 = 0000001b19000006 last_inst = ffffffff
      [ 3003.329421] trap=0xe60 | pc=0xc0000000000c2ba0 | msr=0x8000000000009032
      [ 3003.329524] Severe Hypervisor Maintenance interrupt [Recovered]
      [ 3003.329526]  Error detail: Timer facility experienced an error
      [ 3003.329527] 	HMER: 0840000000000000
      [ 3003.329527] 	TFMR: 4a12000980a94000
      [ 3006.359786] Severe Hypervisor Maintenance interrupt [Recovered]
      [ 3006.359792]  Error detail: Timer facility experienced an error
      [ 3006.359795] 	HMER: 0840000000000000
      [ 3006.359797] 	TFMR: 4a12000980a84000
      
       Id    Name                           State
      ----------------------------------------------------
       2     guest2                         running
       3     guest3                         paused
       4     guest4                         running
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      dee6f24c
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Fix computation of tlbie operand · d506735b
      Paul Mackerras authored
      The B (segment size) field in the RB operand for the tlbie
      instruction is two bits, which we get from the top two bits of
      the first doubleword of the HPT entry to be invalidated.  These
      bits go in bits 8 and 9 of the RB operand (bits 54 and 55 in IBM
      bit numbering).
      
      The compute_tlbie_rb() function gets these bits as v >> (62 - 8),
      which is not correct as it will bring in the top 10 bits, not
      just the top two.  These extra bits could corrupt the AP, AVAL
      and L fields in the RB value.  To fix this we shift right 62 bits
      and then shift left 8 bits, so we only get the two bits of the
      B field.
      
      The first doubleword of the HPT entry is under the control of the
      guest kernel.  In fact, Linux guests will always put zeroes in bits
      54 -- 61 (IBM bits 2 -- 9), but we should not rely on guests doing
      this.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      d506735b
    • Aneesh Kumar K.V's avatar
      KVM: PPC: Book3S HV: Add missing HPTE unlock · f6fb9e84
      Aneesh Kumar K.V authored
      In kvm_test_clear_dirty(), if we find an invalid HPTE we move on to the
      next HPTE without unlocking the invalid one.  In fact we should never
      find an invalid and unlocked HPTE in the rmap chain, but for robustness
      we should unlock it.  This adds the missing unlock.
      Reported-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      f6fb9e84
    • Alexander Graf's avatar
      KVM: PPC: BookE: Improve irq inject tracepoint · b6b61257
      Alexander Graf authored
      When injecting an IRQ, we only document which IRQ priority (which translates
      to IRQ type) gets injected. However, when reading traces you don't necessarily
      have all the numbers in your head to know which IRQ really is meant.
      
      This patch converts the IRQ number field to a symbolic name that is in sync
      with the respective define. That way it's a lot easier for readers to figure
      out what interrupt gets injected.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      b6b61257
  3. 05 Dec, 2014 11 commits
  4. 04 Dec, 2014 18 commits
  5. 03 Dec, 2014 1 commit
  6. 28 Nov, 2014 1 commit