Skip to content
Snippets Groups Projects
  1. May 31, 2010
    • Thomas Monjalon's avatar
      target-ppc: remove useless line · 0f89cc7b
      Thomas Monjalon authored
      
      This line was a bit clear.
      The next lines set or reset this bit (LE) depending of another bit (ILE).
      So the first line is useless.
      
      Signed-off-by: default avatarThomas Monjalon <thomas@monjalon.net>
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      0f89cc7b
    • Thomas Monjalon's avatar
      target-ppc: fix RFI by clearing some bits of MSR · c3d420ea
      Thomas Monjalon authored
      
      Since commit 2ada0ed7, "Return From Interrupt" is broken for PPC processors
      because some interrupt specifics bits of SRR1 are copied to MSR.
      
      SRR1 is a save of MSR during interrupt.
      During RFI, MSR must be restored from SRR1.
      But some bits of SRR1 are interrupt-specific and are not used for MSR saving.
      
      This is the specification (ISA 2.06) at chapter 6.4.3 (Interrupt Processing):
      "2. Bits 33:36 and 42:47 of SRR1 or HSRR1 are loaded with information specific
          to the interrupt type.
       3. Bits 0:32, 37:41, and 48:63 of SRR1 or HSRR1 are loaded with a copy of the
          corresponding bits of the MSR."
      
      Below is a representation of MSR bits which are not saved:
      0:15 16:31 32  33:36    37:41      42:47     48:63
      ——— | ——— | — X X X X — — — — — X X X X X X | ————
      0000 0000 |    7   |   8   |   3   |   F    | 0000
      
      History:
      In the initial Qemu implementation (e1833e1f), the mask 0x783F0000 was used for
      saving MSR in SRR1. But all the bits 32:47 were cleared during RFI restoring.
      This was wrong. The commit 2ada0ed7 explains that this breaks Altivec.
      Indeed, bit 38 (for Altivec support) must be saved and restored.
      The change of 2ada0ed7 was to restore all the bits of SRR1 to MSR.
      But it's also wrong.
      
      Explanation:
      As an example, let's see what's happening after a TLB miss.
      According to the e300 manual (E300CORERM table 5-6), the TLB miss interrupts
      set the bits 44-47 for KEY, I/D, WAY and S/L. These bits are specifics to the
      interrupt and must not be copied into MSR at the end of the interrupt.
      With the current implementation, a TLB miss overwrite bits POW, TGPR and ILE.
      
      Fix:
      It shouldn't be needed to filter-out bits on MSR saving when interrupt occurs.
      Specific bits overwrite MSR ones in SRR1.
      But at the end of interrupt (RFI), specifics bits must be cleared before
      restoring MSR from SRR1. The mask 0x783F0000 apply here.
      
      Discussion:
      The bits of the mask 0x783F0000 are cleared after an interrupt.
      I cannot find a specification which talks about this
      but I assume it is the truth since Linux can run this way.
      Maybe it's not perfect but it's better (works for e300).
      
      Signed-off-by: default avatarThomas Monjalon <thomas@monjalon.net>
      Acked-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      c3d420ea
  2. May 22, 2010
  3. May 18, 2010
    • Alexander Graf's avatar
      PPC/KVM: make iothread work · c821c2bd
      Alexander Graf authored
      
      When running with --enable-io-thread the timer we have doesn't help,
      because it doesn't wake up the CPU thread. So instead we need to
      actually kick it.
      
      While at it I refined the logic a bit to not dumbly trigger a timer
      every 500ms, but rather do it more often after an interrupt got injected.
      If there's no level based interrupt to be expected, we don't need the
      timer anyways.
      
      This makes qemu-system-ppc with --enable-io-thread work when using KVM.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      c821c2bd
  4. May 11, 2010
  5. May 05, 2010
  6. Apr 25, 2010
  7. Apr 18, 2010
    • Blue Swirl's avatar
      PPC: avoid function pointer type mismatch, spotted by clang · 7b13448f
      Blue Swirl authored
      
      Fixes clang errors:
        CC    ppc-softmmu/translate.o
      /src/qemu/target-ppc/translate.c:3748:13: error: comparison of distinct pointer types ('void (*)(void *, int, int)' and 'void *')
              if (likely(read_cb != SPR_NOACCESS)) {
      /src/qemu/target-ppc/translate.c:3748:28: note: instantiated from:
              if (likely(read_cb != SPR_NOACCESS)) {
      /src/qemu/target-ppc/translate.c:3903:13: error: comparison of distinct pointer types ('void (*)(void *, int, int)' and 'void *')
              if (likely(write_cb != SPR_NOACCESS)) {
      /src/qemu/target-ppc/translate.c:3903:29: note: instantiated from:
              if (likely(write_cb != SPR_NOACCESS)) {
      
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
      7b13448f
  8. Mar 26, 2010
  9. Mar 17, 2010
    • Paul Brook's avatar
      Large page TLB flush · d4c430a8
      Paul Brook authored
      
      QEMU uses a fixed page size for the CPU TLB.  If the guest uses large
      pages then we effectively split these into multiple smaller pages, and
      populate the corresponding TLB entries on demand.
      
      When the guest invalidates the TLB by virtual address we must invalidate
      all entries covered by the large page.  However the address used to
      invalidate the entry may not be present in the QEMU TLB, so we do not
      know which regions to clear.
      
      Implementing a full vaiable size TLB is hard and slow, so just keep a
      simple address/mask pair to record which addresses may have been mapped by
      large pages.  If the guest invalidates this region then flush the
      whole TLB.
      
      Signed-off-by: default avatarPaul Brook <paul@codesourcery.com>
      d4c430a8
  10. Mar 12, 2010
  11. Mar 11, 2010
  12. Mar 04, 2010
    • Jan Kiszka's avatar
      KVM: Rework VCPU state writeback API · ea375f9a
      Jan Kiszka authored
      
      This grand cleanup drops all reset and vmsave/load related
      synchronization points in favor of four(!) generic hooks:
      
      - cpu_synchronize_all_states in qemu_savevm_state_complete
        (initial sync from kernel before vmsave)
      - cpu_synchronize_all_post_init in qemu_loadvm_state
        (writeback after vmload)
      - cpu_synchronize_all_post_init in main after machine init
      - cpu_synchronize_all_post_reset in qemu_system_reset
        (writeback after system reset)
      
      These writeback points + the existing one of VCPU exec after
      cpu_synchronize_state map on three levels of writeback:
      
      - KVM_PUT_RUNTIME_STATE (during runtime, other VCPUs continue to run)
      - KVM_PUT_RESET_STATE   (on synchronous system reset, all VCPUs stopped)
      - KVM_PUT_FULL_STATE    (on init or vmload, all VCPUs stopped as well)
      
      This level is passed to the arch-specific VCPU state writing function
      that will decide which concrete substates need to be written. That way,
      no writer of load, save or reset functions that interact with in-kernel
      KVM states will ever have to worry about synchronization again. That
      also means that a lot of reasons for races, segfaults and deadlocks are
      eliminated.
      
      cpu_synchronize_state remains untouched, just as Anthony suggested. We
      continue to need it before reading or writing of VCPU states that are
      also tracked by in-kernel KVM subsystems.
      
      Consequently, this patch removes many cpu_synchronize_state calls that
      are now redundant, just like remaining explicit register syncs.
      
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      ea375f9a
  13. Feb 28, 2010
  14. Feb 27, 2010
  15. Feb 14, 2010
    • Alexander Graf's avatar
      PPC: Add timer when running KVM · c6a94ba5
      Alexander Graf authored
      
      For some odd reason we sometimes hang inside KVM forever. I'd guess it's
      a race condition where we actually have a level triggered interrupt, but
      the infrastructure can't expose that yet, so the guest ACKs it, goes to
      sleep and never gets notified that there's still an interrupt pending.
      
      As a quick workaround, let's just wake up every 500 ms. That way we can
      assure that we're always reinjecting interrupts in time.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      c6a94ba5
    • Alexander Graf's avatar
      PPC: Fix large pages · b2eca445
      Alexander Graf authored
      
      We were masking 1TB SLB entries on the feature bit of 16 MB pages. Obviously
      that breaks, so let's just ignore 1TB SLB entries for now and instead do
      16MB pages correctly.
      
      This fixes PPC64 Linux boot with -m above 256.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      b2eca445
    • Alexander Graf's avatar
      PPC: tell the guest about the time base frequency · dc333cd6
      Alexander Graf authored
      
      Our guest systems need to know by how much the timebase increases every second,
      so there usually is a "timebase-frequency" property in the cpu leaf of the
      device tree.
      
      This property is missing in OpenBIOS.
      
      With qemu, Linux's fallback timebase speed and qemu's internal timebase speed
      match up. With KVM, that is no longer true. The guest is running at the same
      timebase speed as the host.
      
      This leads to massive timing problems. On my test machine, a "sleep 2" takes
      about 14 seconds with KVM enabled.
      
      This patch exports the timebase frequency to OpenBIOS, so it can then put them
      into the device tree.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      dc333cd6
  16. Feb 06, 2010
  17. Jan 19, 2010
  18. Jan 14, 2010
  19. Dec 21, 2009
  20. Dec 19, 2009
  21. Dec 03, 2009
  22. Nov 17, 2009
  23. Nov 12, 2009
  24. Nov 07, 2009
Loading