1. 10 May, 2012 1 commit
  2. 12 Apr, 2012 3 commits
  3. 15 Mar, 2012 1 commit
    • David Gibson's avatar
      kvm: Comparison with ioctl number macros needs to be unsigned · 92e4b519
      David Gibson authored
      In kvm-all.c we store an ioctl cmd number in the irqchip_inject_ioctl field
      of KVMState, which has type 'int'.  This seems to make sense since the
      ioctl() man page says that the cmd parameter has type int.
      
      However, the kernel treats ioctl numbers as unsigned - sys_ioctl() takes an
      unsigned int, and the macros which generate ioctl numbers expand to
      unsigned expressions.  Furthermore, some ioctls (IOC_READ ioctls on x86
      and IOC_WRITE ioctls on powerpc) have bit 31 set, and so would be negative
      if interpreted as an int. This has the surprising and compile-breaking
      consequence that in kvm_irqchip_set_irq() where we do:
          return (s->irqchip_inject_ioctl == KVM_IRQ_LINE) ? 1 : event.status;
      We will get a "comparison is always false due to limited range of data
      type" warning from gcc if KVM_IRQ_LINE is one of the bit-31-set ioctls,
      which it is on powerpc.
      
      So, despite the fact that the man page and posix say ioctl numbers are
      signed, they're actually unsigned.  The kernel uses unsigned, the glibc
      header uses unsigned long, and FreeBSD, NetBSD and OSX also use unsigned
      long ioctl numbers in the code.
      
      Therefore, this patch changes the variable to be unsigned, fixing the
      compile.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      92e4b519
  4. 14 Mar, 2012 1 commit
    • Andreas Färber's avatar
      Rename CPUState -> CPUArchState · 9349b4f9
      Andreas Färber authored
      Scripted conversion:
        for file in *.[hc] hw/*.[hc] hw/kvm/*.[hc] linux-user/*.[hc] linux-user/m68k/*.[hc] bsd-user/*.[hc] darwin-user/*.[hc] tcg/*/*.[hc] target-*/cpu.h; do
          sed -i "s/CPUState/CPUArchState/g" $file
        done
      
      All occurrences of CPUArchState are expected to be replaced by QOM CPUState,
      once all targets are QOM'ified and common fields have been extracted.
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      9349b4f9
  5. 08 Mar, 2012 1 commit
  6. 07 Mar, 2012 2 commits
  7. 01 Mar, 2012 1 commit
    • Avi Kivity's avatar
      kvm: fix unaligned slots · 8f6f962b
      Avi Kivity authored
      kvm_set_phys_mem() may be passed sections that are not aligned to a page
      boundary.  The current code simply brute-forces the alignment which leads
      to an inconsistency and an abort().
      
      Fix by aligning the start and the end of the section correctly, discarding
      and unaligned head or tail.
      
      This was triggered by a guest sizing a 64-bit BAR that is smaller than a page
      with PCI_COMMAND_MEMORY enabled and the upper dword clear.
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      8f6f962b
  8. 29 Feb, 2012 4 commits
  9. 18 Feb, 2012 1 commit
  10. 08 Feb, 2012 1 commit
  11. 01 Feb, 2012 1 commit
  12. 25 Jan, 2012 1 commit
  13. 20 Jan, 2012 1 commit
  14. 19 Jan, 2012 2 commits
    • Jan Kiszka's avatar
      kvm: x86: Establish IRQ0 override control · 9b5b76d4
      Jan Kiszka authored
      KVM is forced to disable the IRQ0 override when we run with in-kernel
      irqchip but without IRQ routing support of the kernel. Set the fwcfg
      value correspondingly. This aligns us with qemu-kvm.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      9b5b76d4
    • Jan Kiszka's avatar
      kvm: Introduce core services for in-kernel irqchip support · 84b058d7
      Jan Kiszka authored
      Add the basic infrastructure to active in-kernel irqchip support, inject
      interrupts into these models, and maintain IRQ routes.
      
      Routing is optional and depends on the host arch supporting
      KVM_CAP_IRQ_ROUTING. When it's not available on x86, we looe the HPET as
      we can't route GSI0 to IOAPIC pin 2.
      
      In-kernel irqchip support will once be controlled by the machine
      property 'kernel_irqchip', but this is not yet wired up.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      84b058d7
  15. 15 Jan, 2012 1 commit
  16. 03 Jan, 2012 1 commit
  17. 20 Dec, 2011 2 commits
  18. 16 Dec, 2011 1 commit
  19. 01 Nov, 2011 1 commit
  20. 24 Oct, 2011 1 commit
  21. 04 Oct, 2011 1 commit
    • Luiz Capitulino's avatar
      RunState: Rename enum values as generated by the QAPI · 0461d5a6
      Luiz Capitulino authored
      Next commit will convert the query-status command to use the
      RunState type as generated by the QAPI.
      
      In order to "transparently" replace the current enum by the QAPI
      one, we have to make some changes to some enum values.
      
      As the changes are simple renames, I'll do them in one shot. The
      changes are:
      
       - Rename the prefix from RSTATE_ to RUN_STATE_
       - RUN_STATE_SAVEVM to RUN_STATE_SAVE_VM
       - RUN_STATE_IN_MIGRATE to RUN_STATE_INMIGRATE
       - RUN_STATE_PANICKED to RUN_STATE_INTERNAL_ERROR
       - RUN_STATE_POST_MIGRATE to RUN_STATE_POSTMIGRATE
       - RUN_STATE_PRE_LAUNCH to RUN_STATE_PRELAUNCH
       - RUN_STATE_PRE_MIGRATE to RUN_STATE_PREMIGRATE
       - RUN_STATE_RESTORE to RUN_STATE_RESTORE_VM
       - RUN_STATE_PRE_MIGRATE to RUN_STATE_FINISH_MIGRATE
      Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      0461d5a6
  22. 15 Sep, 2011 1 commit
    • Luiz Capitulino's avatar
      Replace the VMSTOP macros with a proper state type · 1dfb4dd9
      Luiz Capitulino authored
      Today, when notifying a VM state change with vm_state_notify(),
      we pass a VMSTOP macro as the 'reason' argument. This is not ideal
      because the VMSTOP macros tell why qemu stopped and not exactly
      what the current VM state is.
      
      One example to demonstrate this problem is that vm_start() calls
      vm_state_notify() with reason=0, which turns out to be VMSTOP_USER.
      
      This commit fixes that by replacing the VMSTOP macros with a proper
      state type called RunState.
      Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      1dfb4dd9
  23. 02 Sep, 2011 1 commit
    • Anthony Liguori's avatar
      main: force enabling of I/O thread · 12d4536f
      Anthony Liguori authored
      Enabling the I/O thread by default seems like an important part of declaring
      1.0.  Besides allowing true SMP support with KVM, the I/O thread means that the
      TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
      currently requires a (racey) signal based alarm system.
      
      I know there have been concerns about performance.  I think so far the ones that
      have come up (virtio-net) are most likely due to secondary reasons like
      decreased batching.
      
      I think we ought to force enabling I/O thread early in 1.0 development and
      commit to resolving any lingering issues.
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      12d4536f
  24. 20 Aug, 2011 1 commit
  25. 05 Aug, 2011 1 commit
  26. 20 Jun, 2011 2 commits
  27. 09 May, 2011 1 commit
    • Alexander Graf's avatar
      kvm: ppc: warn user on PAGE_SIZE mismatch · d4d6868f
      Alexander Graf authored
      On PPC, the default PAGE_SIZE is 64kb. Unfortunately, the hardware
      alignments don't match here: There are RAM and MMIO regions within
      a single page when it's 64kb in size.
      
      So the only way out for now is to tell the user that he should use 4k
      PAGE_SIZE.
      
      This patch gives the user a hint on that, telling him that failing to
      register a prefix slot is most likely to be caused by mismatching PAGE_SIZE.
      
      This way it's also more future-proof, as bigger PAGE_SIZE can easily be
      supported by other machines then, as long as they stick to 64kb granularities.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      d4d6868f
  28. 02 May, 2011 3 commits
    • Paolo Bonzini's avatar
      kvm: use qemu_free consistently · 4a043713
      Paolo Bonzini authored
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      4a043713
    • Michael Tokarev's avatar
      fix crash in migration, 32-bit userspace on 64-bit host · 51b0c606
      Michael Tokarev authored
      This change fixes a long-standing immediate crash (memory corruption
      and abort in glibc malloc code) in migration on 32bits.
      
      The bug is present since this commit:
      
        commit 692d9aca97b865b0f7903565274a52606910f129
        Author: Bruce Rogers <brogers@novell.com>
        Date:   Wed Sep 23 16:13:18 2009 -0600
      
          qemu-kvm: allocate correct size for dirty bitmap
      
          The dirty bitmap copied out to userspace is stored in a long array,
          and gets copied out to userspace accordingly.  This patch accounts
          for that correctly.  Currently I'm seeing kvm crashing due to writing
          beyond the end of the alloc'd dirty bitmap memory, because the buffer
          has the wrong size.
      
          Signed-off-by: Bruce Rogers
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      
       --- a/qemu-kvm.c
       +++ b/qemu-kvm.c
       @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned long phys_addr,
       -            buf = qemu_malloc((slots[i].len / 4096 + 7) / 8 + 2);
       +            buf = qemu_malloc(BITMAP_SIZE(slots[i].len));
                   r = kvm_get_map(kvm, KVM_GET_DIRTY_LOG, i, buf);
      
      BITMAP_SIZE is now open-coded in that function, like this:
      
       size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS), HOST_LONG_BITS) / 8;
      
      The problem is that HOST_LONG_BITS in 32bit userspace is 32
      but it's 64 in 64bit kernel.  So userspace aligns this to
      32, and kernel to 64, but since no length is passed from
      userspace to kernel on ioctl, kernel uses its size calculation
      and copies 4 extra bytes to userspace, corrupting memory.
      
      Here's how it looks like during migrate execution:
      
      our=20, kern=24
      our=4, kern=8
      ...
      our=4, kern=8
      our=4064, kern=4064
      our=512, kern=512
      our=4, kern=8
      our=20, kern=24
      our=4, kern=8
      ...
      our=4, kern=8
      our=4064, kern=4064
      *** glibc detected *** ./x86_64-softmmu/qemu-system-x86_64: realloc(): invalid next size: 0x08f20528 ***
      
      (our is userspace size above, kern is the size as calculated
      by the kernel).
      
      Fix this by always aligning to 64 in a hope that no platform will
      have sizeof(long)>8 any time soon, and add a comment describing it
      all.  It's a small price to pay for bad kernel design.
      
      Alternatively it's possible to fix that in the kernel by using
      different size calculation depending on the current process.
      But this becomes quite ugly.
      
      Special thanks goes to Stefan Hajnoczi for spotting the fundamental
      cause of the issue, and to Alexander Graf for his support in #qemu.
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      CC: Bruce Rogers <brogers@novell.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      51b0c606
    • Jan Kiszka's avatar
      kvm: Install specialized interrupt handler · aa7f74d1
      Jan Kiszka authored
      KVM only requires to set the raised IRQ in CPUState and to kick the
      receiving vcpu if it is remote. Installing a specialized handler allows
      potential future changes to the TCG code path without risking KVM side
      effects.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      aa7f74d1
  29. 06 Apr, 2011 1 commit