1. 03 Feb, 2014 1 commit
  2. 17 Jan, 2014 1 commit
  3. 15 Jan, 2014 2 commits
  4. 13 Jan, 2014 3 commits
  5. 25 Nov, 2013 1 commit
  6. 20 Sep, 2013 2 commits
    • Alexey Kardashevskiy's avatar
      kvm irqfd: support direct msimessage to irq translation · 76fe21de
      Alexey Kardashevskiy authored
      On PPC64 systems MSI Messages are translated to system IRQ in a PCI
      host bridge. This is already supported for emulated MSI/MSIX but
      not for irqfd where the current QEMU allocates IRQ numbers from
      irqchip and maps MSIMessages to IRQ in the host kernel.
      
      This adds a new direct mapping flag which tells
      the kvm_irqchip_add_msi_route() function that a new VIRQ
      should not be allocated, instead the value from MSIMessage::data
      should be used. It is up to the platform code to make sure that
      this contains a valid IRQ number as sPAPR does in spapr_pci.c.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      76fe21de
    • Andrew Jones's avatar
      kvm: warn if num cpus is greater than num recommended · 670436ce
      Andrew Jones authored
      The comment in kvm_max_vcpus() states that it's using the recommended
      procedure from the kernel API documentation to get the max number
      of vcpus that kvm supports. It is, but by always returning the
      maximum number supported. The maximum number should only be used
      for development purposes. qemu should check KVM_CAP_NR_VCPUS for
      the recommended number of vcpus. This patch adds a warning if a user
      specifies a number of cpus between the recommended and max.
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Acked-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      670436ce
  7. 12 Sep, 2013 1 commit
  8. 03 Sep, 2013 1 commit
  9. 20 Aug, 2013 2 commits
  10. 09 Aug, 2013 1 commit
  11. 26 Jul, 2013 1 commit
  12. 23 Jul, 2013 2 commits
  13. 09 Jul, 2013 4 commits
    • Andreas Färber's avatar
      cpu: Make first_cpu and next_cpu CPUState · 182735ef
      Andreas Färber authored
      Move next_cpu from CPU_COMMON to CPUState.
      Move first_cpu variable to qom/cpu.h.
      
      gdbstub needs to use CPUState::env_ptr for now.
      cpu_copy() no longer needs to save and restore cpu_next.
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [AF: Rebased, simplified cpu_copy()]
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      182735ef
    • Andreas Färber's avatar
    • Andreas Färber's avatar
      kvm: Free current_cpu identifier · 80b7cd73
      Andreas Färber authored
      Since CPU loops are done as last step in kvm_{insert,remove}_breakpoint()
      and kvm_remove_all_breakpoints(), we do not need to distinguish between
      invoking CPU and iterated CPUs and can thereby free the identifier for
      use as a global variable.
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      80b7cd73
    • Markus Armbruster's avatar
      Fix -machine options accel, kernel_irqchip, kvm_shadow_mem · 36ad0e94
      Markus Armbruster authored
      Multiple -machine options with the same ID are merged.  All but the
      one without an ID are to be silently ignored.
      
      In most places, we query these options with a null ID.  This is
      correct.
      
      In some places, we instead query whatever options come first in the
      list.  This is wrong.  When the -machine processed first happens to
      have an ID, options are taken from that ID, and the ones specified
      without ID are silently ignored.
      
      Example:
      
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine id=foo -machine accel=kvm,usb=on
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine id=foo,accel=kvm,usb=on -machine accel=xen
          $ upstream-qemu -nodefaults -S -display none -monitor stdio -machine accel=xen -machine id=foo,accel=kvm,usb=on
      
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine accel=kvm,usb=on
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: enabled
          (qemu) info usb
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine id=foo -machine accel=kvm,usb=on
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: disabled
          (qemu) info usb
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine id=foo,accel=kvm,usb=on -machine accel=xen
          QEMU 1.5.50 monitor - type 'help' for more information
          (qemu) info kvm
          kvm support: enabled
          (qemu) info usb
          USB support not enabled
          (qemu) q
          $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -machine accel=xen -machine id=foo,accel=kvm,usb=on
          xc: error: Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
          xen be core: can't open xen interface
          failed to initialize Xen: Operation not permitted
      
      Option usb is queried correctly, and the one without an ID wins,
      regardless of option order.
      
      Option accel is queried incorrectly, and which one wins depends on
      option order and ID.
      
      Affected options are accel (and its sugared forms -enable-kvm and
      -no-kvm), kernel_irqchip, kvm_shadow_mem.
      
      Additionally, option kernel_irqchip is normally on by default, except
      it's off when no -machine options are given.  Bug can't bite, because
      kernel_irqchip is used only when KVM is enabled, KVM is off by
      default, and enabling always creates -machine options.  Downstreams
      that enable KVM by default do get bitten, though.
      
      Use qemu_get_machine_opts() to fix these bugs.
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-id: 1372943363-24081-5-git-send-email-armbru@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      36ad0e94
  14. 04 Jul, 2013 1 commit
    • Paolo Bonzini's avatar
      memory: add ref/unref calls · dfde4e6e
      Paolo Bonzini authored
      Add ref/unref calls at the following places:
      
      - places where memory regions are stashed by a listener and
        used outside the BQL (including in Xen or KVM).
      
      - memory_region_find callsites
      
      - creation of aliases and containers (only the aliased/contained
        region gets a reference to avoid loops)
      
      - around calls to del_subregion/add_subregion, where the region
        could disappear after the first call
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      dfde4e6e
  15. 03 Jul, 2013 3 commits
  16. 30 Jun, 2013 4 commits
    • Alexander Graf's avatar
      KVM: PIC: Only commit irq routing when necessary · cb925cf9
      Alexander Graf authored
      The current logic updates KVM's view of our interrupt map every time we
      change it. While this is nice and bullet proof, it slows things down
      badly for me. QEMU spends about 3 seconds on every start telling KVM what
      news it has on its routing maps.
      
      Instead, let's just synchronize the whole irq routing map as a whole when
      we're done constructing it. For things that change during runtime, we can
      still update the routing table on demand.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      cb925cf9
    • Alexander Graf's avatar
      KVM: MSI: Swap payload to native endianness · d07cc1f1
      Alexander Graf authored
      The usual MSI injection mechanism writes msi.data into memory using an
      le32 wrapper. So on big endian guests, this swaps msg.data into the
      expected byte order.
      
      For irqfd however, we don't swap the payload right now, rendering
      in-kernel MPIC emulation broken on PowerPC.
      
      Swap msg.data to the correct endianness whenever we touch it.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      d07cc1f1
    • Alexander Graf's avatar
      KVM: Export kvm_init_irq_routing · 7b774593
      Alexander Graf authored
      On PPC, we can have different types of interrupt controllers, so we really
      only know that we are going to use one when we created it.
      
      Export kvm_init_irq_routing() to common code, so that we don't have to call
      kvm_irqchip_create().
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      7b774593
    • Alexander Graf's avatar
      KVM: Don't assume that mpstate exists with in-kernel PIC always · 215e79c0
      Alexander Graf authored
      On PPC, we don't support MP state. So far it's not necessary and I'm
      not convinced yet that we really need to support it ever.
      
      However, the current idle logic in QEMU assumes that an in-kernel PIC
      also means we support MP state. This assumption is not true anymore.
      
      Let's split up the two cases into two different variables. That way
      PPC can expose an in-kernel PIC, while not implementing MP state.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      CC: Jan Kiszka <jan.kiszka@siemens.com>
      215e79c0
  17. 28 Jun, 2013 5 commits
  18. 20 Jun, 2013 1 commit
    • Paolo Bonzini's avatar
      memory: make section size a 128-bit integer · 052e87b0
      Paolo Bonzini authored
      So far, the size of all regions passed to listeners could fit in 64 bits,
      because artificial regions (containers and aliases) are eliminated by
      the memory core, leaving only device regions which have reasonable sizes
      
      An IOMMU however cannot be eliminated by the memory core, and may have
      an artificial size, hence we may need 65 bits to represent its size.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      052e87b0
  19. 03 Jun, 2013 1 commit
  20. 29 May, 2013 2 commits
  21. 14 May, 2013 1 commit