1. 05 Jun, 2017 5 commits
    • David Gibson's avatar
      migration: Mark CPU states dirty before incoming migration/loadvm · 75e972da
      David Gibson authored
      As a rule, CPU internal state should never be updated when
      !cpu->kvm_vcpu_dirty (or the HAX equivalent).  If that is done, then
      subsequent calls to cpu_synchronize_state() - usually safe and idempotent -
      will clobber state.
      
      However, we routinely do this during a loadvm or incoming migration.
      Usually this is called shortly after a reset, which will clear all the cpu
      dirty flags with cpu_synchronize_all_post_reset().  Nothing is expected
      to set the dirty flags again before the cpu state is loaded from the
      incoming stream.
      
      This means that it isn't safe to call cpu_synchronize_state() from a
      post_load handler, which is non-obvious and potentially inconvenient.
      
      We could cpu_synchronize_all_state() before the loadvm, but that would be
      overkill since a) we expect the state to already be synchronized from the
      reset and b) we expect to completely rewrite the state with a call to
      cpu_synchronize_all_post_init() at the end of qemu_loadvm_state().
      
      To clear this up, this patch introduces cpu_synchronize_pre_loadvm() and
      associated helpers, which simply marks the cpu state as dirty without
      actually changing anything.  i.e. it says we want to discard any existing
      KVM (or HAX) state and replace it with what we're going to load.
      
      Cc: Juan Quintela <quintela@redhat.com>
      Cc: Dave Gilbert <dgilbert@redhat.com>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarJuan Quintela <quintela@redhat.com>
      75e972da
    • Igor Mammedov's avatar
      numa: move numa_node from CPUState into target specific classes · 15f8b142
      Igor Mammedov authored
      Move vcpu's associated numa_node field out of generic CPUState
      into inherited classes that actually care about cpu<->numa mapping,
      i.e: ARMCPU, PowerPCCPU, X86CPU.
      Signed-off-by: 's avatarIgor Mammedov <imammedo@redhat.com>
      Message-Id: <1496161442-96665-6-git-send-email-imammedo@redhat.com>
      [ehabkost: s/CPU is belonging to/CPU belongs to/ on comments]
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      15f8b142
    • Emilio G. Cota's avatar
      target/i386: optimize indirect branches · b4aa2977
      Emilio G. Cota authored
      Speed up indirect branches by jumping to the target if it is valid.
      
      Softmmu measurements (see later commit for user-mode numbers):
      
      Note: baseline (i.e. speedup == 1x) is QEMU v2.9.0.
      
      -                  SPECint06 (test set), x86_64-softmmu (Ubuntu 16.04 guest). Host: Intel i7-4790K @ 4.00GHz
      
       2.4x +-+--------------------------------------------------------------------------------------------------------------+-+
            |                                                                                                                  |
            |   cross                                                                                                          |
       2.2x +cross+jr..........................................................................+++...........................+-+
            |                                                                                   |                              |
            |                                                                               +++ |                              |
         2x +-+..............................................................................|..|............................+-+
            |                                                                                |  |                              |
            |                                                                                |  |                              |
       1.8x +-+..............................................................................|####...........................+-+
            |                                                                                |# |#                             |
            |                                                                              **** |#                             |
       1.6x +-+............................................................................*.|*.|#...........................+-+
            |                                                                              * |* |#                             |
            |                                                                              * |* |#                             |
       1.4x +-+.......................................................................+++..*.|*.|#...........................+-+
            |                                                      ++++++             #### * |*++#             +++             |
            |                        +++                            |  |              #++# *++*  #          +++ |              |
       1.2x +-+......................###.....####....+++............|..|...........****..#.*..*..#....####...|.###.....####..+-+
            |        +++          **** #  ****  #    ####          ***###          *++*  # *  *  #    #++#  ****|#  +++#++#    |
            |    ****###     +++  *++* #  *++*  #  ++#  #    ####  *|* |#     +++  *  *  # *  *  #  ***  #  *| *|#  ****  #    |
         1x +-++-*++*++#++***###++*++*+#++*+-*++#+****++#++***++#+-*+*++#-+****##++*++*-+#+*++*-+#++*+*++#++*-+*+#++*++*++#-++-+
            |    *  *  #  * *  #  *  * #  *  *  # *  *  #  * *  #  *|* |#  *++* #  *  *  # *  *  #  * *  #  *  * #  *  *  #    |
            |    *  *  #  * *  #  *  * #  *  *  # *  *  #  * *  #  *+*++#  *  * #  *  *  # *  *  #  * *  #  *  * #  *  *  #    |
       0.8x +-+--****###--***###--****##--****###-****###--***###--***###--****##--****###-****###--***###--****##--****###--+-+
               astar   bzip2      gcc   gobmk h264ref   hmmlibquantum      mcf omnetpperlbench   sjengxalancbmk   hmean
        png: http://imgur.com/DU36YFU
      
      NB. 'cross' represents the previous commit.
      Reviewed-by: 's avatarAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: 's avatarRichard Henderson <rth@twiddle.net>
      Signed-off-by: 's avatarEmilio G. Cota <cota@braap.org>
      Message-Id: <1493263764-18657-11-git-send-email-cota@braap.org>
      Signed-off-by: 's avatarRichard Henderson <rth@twiddle.net>
      b4aa2977
    • Emilio G. Cota's avatar
      target/i386: optimize cross-page direct jumps in softmmu · fe620895
      Emilio G. Cota authored
      Instead of unconditionally exiting to the exec loop, use the
      gen_jr helper to jump to the target if it is valid.
      
      Perf impact: see next commit's log.
      Reviewed-by: 's avatarRichard Henderson <rth@twiddle.net>
      Signed-off-by: 's avatarEmilio G. Cota <cota@braap.org>
      Message-Id: <1493263764-18657-10-git-send-email-cota@braap.org>
      Signed-off-by: 's avatarRichard Henderson <rth@twiddle.net>
      fe620895
    • Emilio G. Cota's avatar
      target/i386: introduce gen_jr helper to generate lookup_and_goto_ptr · 1ebb1af1
      Emilio G. Cota authored
      This helper will be used by subsequent changes.
      Reviewed-by: 's avatarAlex Bennée <alex.bennee@linaro.org>
      Signed-off-by: 's avatarEmilio G. Cota <cota@braap.org>
      Message-Id: <1493263764-18657-9-git-send-email-cota@braap.org>
      Signed-off-by: 's avatarRichard Henderson <rth@twiddle.net>
      1ebb1af1
  2. 23 May, 2017 1 commit
    • Eric Blake's avatar
      shutdown: Add source information to SHUTDOWN and RESET · cf83f140
      Eric Blake authored
      Time to wire up all the call sites that request a shutdown or
      reset to use the enum added in the previous patch.
      
      It would have been less churn to keep the common case with no
      arguments as meaning guest-triggered, and only modified the
      host-triggered code paths, via a wrapper function, but then we'd
      still have to audit that I didn't miss any host-triggered spots;
      changing the signature forces us to double-check that I correctly
      categorized all callers.
      
      Since command line options can change whether a guest reset request
      causes an actual reset vs. a shutdown, it's easy to also add the
      information to reset requests.
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts]
      Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part]
      Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts]
      Message-Id: <20170515214114.15442-5-eblake@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      cf83f140
  3. 17 May, 2017 2 commits
    • Eduardo Habkost's avatar
      qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable · e90f2a8c
      Eduardo Habkost authored
      cannot_instantiate_with_device_add_yet was introduced by commit
      efec3dd6 to replace no_user. It was
      supposed to be a temporary measure.
      
      When it was introduced, we had 54
      cannot_instantiate_with_device_add_yet=true lines in the code.
      Today (3 years later) this number has not shrunk: we now have
      57 cannot_instantiate_with_device_add_yet=true lines. I think it
      is safe to say it is not a temporary measure, and we won't see
      the flag go away soon.
      
      Instead of a long field name that misleads people to believe it
      is temporary, replace it a shorter and less misleading field:
      user_creatable.
      
      Except for code comments, changes were generated using the
      following Coccinelle patch:
      
        @@
        expression DC;
        @@
        (
        -DC->cannot_instantiate_with_device_add_yet = false;
        +DC->user_creatable = true;
        |
        -DC->cannot_instantiate_with_device_add_yet = true;
        +DC->user_creatable = false;
        )
      
        @@
        typedef ObjectClass;
        expression dc;
        identifier class, data;
        @@
         static void device_class_init(ObjectClass *class, void *data)
         {
         ...
         dc->hotpluggable = true;
        +dc->user_creatable = true;
         ...
         }
      
        @@
        @@
         struct DeviceClass {
         ...
        -bool cannot_instantiate_with_device_add_yet;
        +bool user_creatable;
         ...
        }
      
        @@
        expression DC;
        @@
        (
        -!DC->cannot_instantiate_with_device_add_yet
        +DC->user_creatable
        |
        -DC->cannot_instantiate_with_device_add_yet
        +!DC->user_creatable
        )
      
      Cc: Alistair Francis <alistair.francis@xilinx.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Marcel Apfelbaum <marcel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Thomas Huth <thuth@redhat.com>
      Acked-by: 's avatarAlistair Francis <alistair.francis@xilinx.com>
      Reviewed-by: 's avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: 's avatarMarcel Apfelbaum <marcel@redhat.com>
      Acked-by: 's avatarMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-2-ehabkost@redhat.com>
      [ehabkost: kept "TODO remove once we're there" comment]
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      e90f2a8c
    • Juan Quintela's avatar
      migration: Create migration/blocker.h · 795c40b8
      Juan Quintela authored
      This allows us to remove lots of includes of migration/migration.h
      Signed-off-by: 's avatarJuan Quintela <quintela@redhat.com>
      Reviewed-by: 's avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: 's avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      795c40b8
  4. 11 May, 2017 5 commits
  5. 05 May, 2017 2 commits
    • Yu Ning's avatar
      hax: Fix memory mapping de-duplication logic · 8a3c3d99
      Yu Ning authored
      hax_update_mapping() avoids unnecessary and potentially expensive
      calls to HAX_VM_IOCTL_SET_RAM by computing the net result (i.e.
      effective mapping changes) of each MemoryRegion transaction, with
      the help of a linked list of HAXMapping objects.
      
      However, when processing a new mapping that overlaps with an
      existing mapping in the list, it fails to handle the case where the
      start address of the new mapping is above that of the existing
      mapping in the guest physical address space. This happens when QEMU
      is launched with "-machine q35 -enable-hax", which involves the
      following MemoryRegion transaction for digging the VGA hole:
      
       region_del: 0x00000000->0x08000000 VA 05fa0000 ('pc.ram')
       region_add: 0x00000000->0x000a0000 VA 05fa0000 ('pc.ram')
       region_add: 0x000a0000->0x000c0000 VA 00000000 ('vga-lowmem')
       region_add: 0x000c0000->0x08000000 VA 06060000 ('pc.ram')
      
      where the third MemoryRegion is MMIO and is ignored. The current
      de-duplication logic handles the last MemoryRegion incorrectly and
      produces the following result:
      
       hax_mapping_dump_list updates:
               + 0x000c0000->0x08000000 VA 0x06060000
               - 0x07fe0000->0x08000000 VA 0x0df80000
      
      which is why VGA emulation does not work for Q35.
      
      With this patch, one can see VGA output as Q35 boots up. Note that
      Q35 support also requires a change to HAXM kernel module, which is
      not available in the current HAXM release (6.1.2).
      
      + Add a warning if the input MemoryRegion is a ROM device, which is
        not supported by HAXM kernel module at this time.
      Signed-off-by: 's avatarYu Ning <yu.ning@linux.intel.com>
      Message-Id: <20170428072723.7036-1-yu.ning@linux.intel.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      8a3c3d99
    • Abdallah Bouassida's avatar
      target/i386: Add GDB XML register description support · 00fcd100
      Abdallah Bouassida authored
      This patch implements XML target description support for X86 and X86-64
      architectures in the GDB stub, as the way with ARM and PowerPC:
      - gdb-xml/32bit-core.xml & gdb-xml/64bit-core.xml: Adding the XML target
        description files, these files are picked from GDB source code.
      - configure: Define gdb_xml_files for X86 targets.
      - target/i386/cpu.c: Define gdb_core_xml_file and gdb_arch_name to add
        XML awareness for this architecture, modify the gdb_num_core_regs to
        fit the registers number defined in each XML file.
      Signed-off-by: 's avatarAbdallah Bouassida <abdallah.bouassida@lauterbach.com>
      Message-Id: <2b3c8119-1602-28c7-eab4-296593877103@lauterbach.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      00fcd100
  6. 10 Apr, 2017 1 commit
  7. 02 Apr, 2017 1 commit
  8. 31 Mar, 2017 1 commit
  9. 28 Mar, 2017 2 commits
  10. 24 Mar, 2017 1 commit
  11. 14 Mar, 2017 1 commit
  12. 10 Mar, 2017 3 commits
  13. 09 Mar, 2017 2 commits
  14. 03 Mar, 2017 6 commits
  15. 27 Feb, 2017 7 commits
    • Pranith Kumar's avatar
      linux-user: Add signal handling support for x86_64 · 1c1df019
      Pranith Kumar authored
      Note that x86_64 has only _rt signal handlers. This implementation
      attempts to share code with the x86_32 implementation.
      
      CC: Laurent Vivier <laurent@vivier.eu>
      Signed-off-by: 's avatarAllan Wirth <awirth@akamai.com>
      Reviewed-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarPranith Kumar <bobby.prani@gmail.com>
      Reviewed-by: 's avatarLaurent Vivier <laurent@vivier.eu>
      Message-Id: <20170226165345.8757-1-bobby.prani@gmail.com>
      Signed-off-by: 's avatarLaurent Vivier <laurent@vivier.eu>
      1c1df019
    • Eduardo Habkost's avatar
      i386: Improve query-cpu-model-expansion full mode · b8097deb
      Eduardo Habkost authored
      This keeps the same results on type=static expansion, but make
      type=full expansion return every single QOM property on the CPU
      object that have a different value from the "base' CPU model,
      plus all the CPU feature flag properties.
      
      Cc: Jiri Denemark <jdenemar@redhat.com>
      Message-Id: <20170222190029.17243-4-ehabkost@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      b8097deb
    • Eduardo Habkost's avatar
      i386: Implement query-cpu-model-expansion QMP command · f99fd7ca
      Eduardo Habkost authored
      Implement query-cpu-model-expansion for target-i386.
      
      This should meet all the requirements while being simple. In the
      case of static expansion, it will use the new "base" CPU model,
      and in the case of full expansion, it will keep the original CPU
      model name+props, and append extra properties.
      
      A future follow-up should improve the implementation of
      type=full, so that it returns more detailed data, including every
      writable QOM property in the CPU object.
      
      Cc: libvir-list@redhat.com
      Cc: Jiri Denemark <jdenemar@redhat.com>
      Message-Id: <20170222190029.17243-3-ehabkost@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      f99fd7ca
    • Eduardo Habkost's avatar
      i386: Define static "base" CPU model · 5adbed30
      Eduardo Habkost authored
      The query-cpu-model-expand QMP command needs at least one static
      model, to allow the "static" expansion mode to be implemented.
      Instead of defining static versions of every CPU model, define a
      "base" CPU model that has absolutely no feature flag enabled.
      
      Despite having no CPUID data set at all, "-cpu base" is even a
      functional CPU:
      
      * It can boot a Slackware Linux 1.01 image with a Linux 0.99.12
        kernel[1].
      * It is even possible to boot[2] a modern Fedora x86_64 guest by
        manually enabling the following CPU features:
        -cpu base,+lm,+msr,+pae,+fpu,+cx8,+cmov,+sse,+sse2,+fxsr
      
      [1] http://www.qemu-advent-calendar.org/2014/#day-1
      [2] This is what can be seen in the guest:
          [root@localhost ~]# cat /proc/cpuinfo
          processor       : 0
          vendor_id       : unknown
          cpu family      : 0
          model           : 0
          model name      : 00/00
          stepping        : 0
          physical id     : 0
          siblings        : 1
          core id         : 0
          cpu cores       : 1
          apicid          : 0
          initial apicid  : 0
          fpu             : yes
          fpu_exception   : yes
          cpuid level     : 1
          wp              : yes
          flags           : fpu msr pae cx8 cmov fxsr sse sse2 lm nopl
          bugs            :
          bogomips        : 5832.70
          clflush size    : 64
          cache_alignment : 64
          address sizes   : 36 bits physical, 48 bits virtual
          power management:
      
          [root@localhost ~]# x86info -v -a
          x86info v1.30.  Dave Jones 2001-2011
          Feedback to <davej@redhat.com>.
      
          No TSC, MHz calculation cannot be performed.
          Unknown vendor (0)
          MP Table:
      
          Family: 0 Model: 0 Stepping: 0
          CPU Model (x86info's best guess):
      
          eax in: 0x00000000, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 00000000
          eax in: 0x00000001, eax = 00000000 ebx = 00000800 ecx = 00000000 edx = 07008161
      
          eax in: 0x80000000, eax = 80000001 ebx = 00000000 ecx = 00000000 edx = 00000000
          eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 20000000
      
          Feature flags:
           fpu            Onboard FPU
           msr            Model-Specific Registers
           pae            Physical Address Extensions
           cx8            CMPXCHG8 instruction
           cmov           CMOV instruction
           fxsr           FXSAVE and FXRSTOR instructions
           sse            SSE support
           sse2           SSE2 support
      
          Long NOPs supported: yes
      
          Address sizes : 0 bits physical, 0 bits virtual
          0MHz processor (estimate).
      
           running at an estimated 0MHz
          [root@localhost ~]#
      
      Message-Id: <20170222190029.17243-2-ehabkost@redhat.com>
      Reviewed-by: 's avatarDavid Hildenbrand <david@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      5adbed30
    • Eduardo Habkost's avatar
      i386: Don't set CPUClass::cpu_def on "max" model · 0bacd8b3
      Eduardo Habkost authored
      Host CPUID info is used by the "max" CPU model only in KVM mode.
      Move the initialization of CPUID data for "max" from class_init
      to instance_init, and don't set CPUClass::cpu_def for "max".
      
      Message-Id: <20170222183919.11928-4-ehabkost@redhat.com>
      Tested-by: 's avatarRichard W.M. Jones <rjones@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      0bacd8b3
    • Eduardo Habkost's avatar
      i386: Make "max" model not use any host CPUID info on TCG · 6900d1cc
      Eduardo Habkost authored
      Instead of reporting host CPUID data on "max", use the qemu64 CPU
      model as reference to initialize CPUID
      vendor/family/model/stepping/model-id.
      
      Message-Id: <20170222183919.11928-3-ehabkost@redhat.com>
      Tested-by: 's avatarRichard W.M. Jones <rjones@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      6900d1cc
    • Eduardo Habkost's avatar
      i386: Create "max" CPU model · c62f2630
      Eduardo Habkost authored
      Rename the existing "host" CPU model to "max, and set it to
      kvm_enabled=false. The new "max" CPU model will be able to enable
      all features supported by TCG out of the box, because its logic
      is based on x86_cpu_get_supported_feature_word(), which already
      works with TCG.
      
      A new KVM-specific "host" class was added, that simply inherits
      everything from "max" except the 'ordering' and 'description'
      fields.
      
      Message-Id: <20170222183919.11928-2-ehabkost@redhat.com>
      Tested-by: 's avatarRichard W.M. Jones <rjones@redhat.com>
      Tested-by: 's avatarJiri Denemark <jdenemar@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      c62f2630