summaryrefslogtreecommitdiff
path: root/target/i386
AgeCommit message (Collapse)AuthorFilesLines
2017-06-15hax-all: make async_safe_run_on_cpu safe on HAX tooPaolo Bonzini1-1/+2
While at it, drop the current_cpu assignment since this is a per-thread variable on modern QEMU. Cc: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07kvm: don't register smram_listener when smm is offGonglei1-1/+3
If the user set disable smm by '-machine smm=off', we should not register smram_listener so that we can avoid waster memory in kvm since the added sencond address space. Meanwhile we should assign value of the global kvm_state before invoking the kvm_arch_init(), because pc_machine_is_smm_enabled() may use it by kvm_has_mm(). Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1496316915-121196-1-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07target/i386: Add GDB XML description for SSE registersAbdallah Bouassida1-4/+4
Add an XML description for SSE registers (XMM+MXCSR) for both X86 and X86-64 architectures in the GDB stub: - configure: Define gdb_xml_files for the X86 targets (32 and 64bit). - gdb-xml/i386-32bit-sse.xml & gdb-xml/i386-64bit-sse.xml: The XML files that contain a description of the XMM + MXCSR registers. - gdb-xml/i386-32bit.xml & gdb-xml/i386-64bit.xml: wrappers that include the XML file of the core registers and the other XML file of the SSE registers. - target/i386/cpu.c: Modify the gdb_core_xml_file to the new XML wrapper, modify the gdb_num_core_regs to fit the registers number defined in each XML file. Signed-off-by: Abdallah Bouassida <abdallah.bouassida@lauterbach.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07i386/kvm: do not zero out segment flags if segment is unusable or not presentRoman Pen1-12/+8
This is a fix for the problem [1], where VMCB.CPL was set to 0 and interrupt was taken on userspace stack. The root cause lies in the specific AMD CPU behaviour which manifests itself as unusable segment attributes on SYSRET[2]. Here in this patch flags are not touched even segment is unusable or is not present, therefore CPL (which is stored in DPL field) should not be lost and will be successfully restored on kvm/svm kernel side. Also current patch should not break desired behavior described in this commit: 4cae9c97967a ("target-i386: kvm: clear unusable segments' flags in migration") since present bit will be dropped if segment is unusable or is not present. This is the second part of the whole fix of the corresponding problem [1], first part is related to kvm/svm kernel side and does exactly the same: segment attributes are not zeroed out. [1] Message id: CAJrWOzD6Xq==b-zYCDdFLgSRMPM-NkNuTSDFEtX=7MreT45i7Q@mail.gmail.com [2] Message id: 5d120f358612d73fc909f5bfa47e7bd082db0af0.1429841474.git.luto@kernel.org Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com> Signed-off-by: Mikhail Sennikovskii <mikhail.sennikovskii@profitbricks.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Michael Chapman <mike@very.puzzling.org> Cc: qemu-devel@nongnu.org Message-Id: <20170601085604.12980-1-roman.penyaev@profitbricks.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07i386: fix read/write cr with icount optionMihail Abakumov1-0/+12
Running Windows with icount causes a crash in instruction of write cr. This patch fixes it. Reading and writing cr cause an icount read because there are called cpu_get_apic_tpr and cpu_set_apic_tpr functions. So, there is need gen_io_start()/gen_io_end() calls. Signed-off-by: Mihail Abakumov <mikhail.abakumov@ispras.ru> Message-Id: <ffb376034ff184f2fcbe93d5317d9e76@ispras.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07target/i386: use multiple CPU AddressSpacesPaolo Bonzini5-55/+47
This speeds up SMM switches. Later on it may remove the need to take the BQL, and it may also allow to reuse code between TCG and KVM. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07target/i386: enable A20 automatically in system management modePaolo Bonzini3-27/+42
Ignore env->a20_mask when running in system management mode. Reported-by: Anthony Xu <anthony.xu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1494502528-12670-1-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-06kvm: irqchip: skip update msi when disabledPeter Xu1-3/+9
It's possible that one device kept its irqfd/virq there even when MSI/MSIX was disabled globally for that device. One example is virtio-net-pci (see commit f1d0f15a6 and virtio_pci_vq_vector_mask()). It is used as a fast path to avoid allocate/release irqfd/virq frequently when guest enables/disables MSIX. However, this fast path brought a problem to msi_route_list, that the device MSIRouteEntry is still dangling there even if MSIX disabled - then we cannot know which message to fetch, even if we can, the messages are meaningless. In this case, we can just simply ignore this entry. It's safe, since when MSIX is enabled again, we'll rebuild them no matter what. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1448813 Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1494309644-18743-4-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-06Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170606' ↵Peter Maydell1-0/+10
into staging ppc patch queue 2017-06-06 Accumulated patches for ppc targets and the pseries machine type. The big thing in this batch is a start on a substantial cleanup of the pseries hotplug mechanisms, which were pretty confusing. For now these shouldn't cause substantial behavioural changes, but I am hoping these lead to clearer code and eventually to fixes for the bugs we have in hotplug handling, particularly when hotplug and migration are combined. The remaining patches are mostly bugfixes. # gpg: Signature made Tue 06 Jun 2017 03:48:50 BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.10-20170606: spapr: Remove some non-useful properties on DRC objects spapr: Eliminate spapr_drc_get_type_str() spapr: Move configure-connector state into DRC spapr: Clean up spapr_dr_connector_by_*() spapr: Introduce DRC subclasses spapr/drc: don't migrate DRC of cold-plugged CPUs and LMBs spapr: Allow boot from vhost-*-scsi backends ppc/pnv: check the return value of fdt_setprop() spapr_nvram: Check return value from blk_getlength() target/ppc: Fixup set_spr error in h_register_process_table target-ppc: Fix openpic timer read register offset spapr: Make DRC get_index and get_type methods into plain functions spapr: Abolish DRC set_configured method spapr: Abolish DRC get_fdt method spapr: Move DRC RTAS calls into spapr_drc.c migration: Mark CPU states dirty before incoming migration/loadvm migration: remove register_savevm() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-06Merge remote-tracking branch ↵Peter Maydell2-1/+2
'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging x86 and machine queue, 2017-06-05 # gpg: Signature made Mon 05 Jun 2017 19:58:01 BST # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-and-machine-pull-request: scripts: Test script to look for -device crashes qemu.py: Add QEMUMachine.exitcode() method qemu.py: Don't set _popen=None on error/shutdown spapr: cleanup spapr_fixup_cpu_numa_dt() usage numa: move numa_node from CPUState into target specific classes numa: make hmp 'info numa' fetch numa nodes from qmp_query_cpus() result numa: make sure that all cpus have has_node_id set if numa is enabled numa: move default mapping init to machine numa: consolidate cpu_preplug fixups/checks for pc/arm/spapr pc: Use "min-[x]level" on compat_props Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-06migration: Mark CPU states dirty before incoming migration/loadvmDavid Gibson1-0/+10
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: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Juan Quintela <quintela@redhat.com>
2017-06-05numa: move numa_node from CPUState into target specific classesIgor Mammedov2-1/+2
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: Igor 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: Eduardo Habkost <ehabkost@redhat.com>
2017-06-05target/i386: optimize indirect branchesEmilio G. Cota1-6/+8
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: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1493263764-18657-11-git-send-email-cota@braap.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
2017-06-05target/i386: optimize cross-page direct jumps in softmmuEmilio G. Cota1-2/+2
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1493263764-18657-10-git-send-email-cota@braap.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
2017-06-05target/i386: introduce gen_jr helper to generate lookup_and_goto_ptrEmilio G. Cota1-1/+24
This helper will be used by subsequent changes. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1493263764-18657-9-git-send-email-cota@braap.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
2017-05-23shutdown: Add source information to SHUTDOWN and RESETEric Blake4-6/+6
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: Eric 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: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-18Merge remote-tracking branch 'quintela/tags/migration/20170517' into stagingStefan Hajnoczi1-1/+1
migration/next for 20170517 # gpg: Signature made Wed 17 May 2017 11:46:36 AM BST # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * quintela/tags/migration/20170517: migration: Move check_migratable() into qdev.c migration: Move postcopy stuff to postcopy-ram.c migration: Move page_cache.c to migration/ migration: Create migration/blocker.h ram: Rename RAM_SAVE_FLAG_COMPRESS to RAM_SAVE_FLAG_ZERO migration: Pass Error ** argument to {save,load}_vmstate migration: Fix regression with compression threads Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-17qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatableEduardo Habkost1-1/+1
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc 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: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17migration: Create migration/blocker.hJuan Quintela1-1/+1
This allows us to remove lots of includes of migration/migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-11migration/i386: Remove support for pre-0.12 formatsDr. David Alan Gilbert1-81/+34
Remove support for versions of the CPU state prior to 11 which is the version used in qemu 0.12 - you'd be pretty lucky if you got a migration stream to work from anything that old anyway. This doesn't affect the machine type definition in any way. My main reason for doing this is the hack for sysenter_esp/eip that uses .get/.put's in state versions less than 7 (that's prior to somewhere before 0.10). Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170405190024.27581-4-dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11vmstatification: i386 FPRegDr. David Alan Gilbert1-22/+30
Convert the fpreg save/restore to use VMSTATE_ macros rather than .get/.put. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170405190024.27581-3-dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11migration/i386: Remove old non-softfloat 64bit FP supportDr. David Alan Gilbert1-101/+6
Long long ago, we used to support storing the x86 FP registers in a 64bit format. Then c31da136a0bf8caad70c348f5ffc283206e9c7fc in v0.14-rc0 removed the last support for writing that in the migration format. Even before that, it was only used if you had softfloat disabled (i.e. !USE_X86LDOUBLE) so in practice use of it in even earlier qemu is unlikely for most users. Kill it off, it's complicated, and possibly broken. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170405190024.27581-2-dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11pc: add node-id property to CPUIgor Mammedov1-0/+1
it will allow switching from cpu_index to property based numa mapping in follow up patches. PS: patch changes default value of CPUState::numa_node from 0 to CPU_UNSET_NUMA_NODE_ID. The only place for x86 that would affected is monitor's 'infor numa' command which uses that field. However legacy 0 value is still preserved by pc_cpu_pre_plug() in this patch if user/numa.c hasn't set it explicitly, so there is no change in behavior. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1494415802-227633-4-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11i386: rewrite way CPUID index is validatedDaniel P. Berrange1-20/+15
Change the nested if statements into a flat format, to make it clearer what validation / capping is being performed on different CPUID index values. NB this changes behaviour when "index > env->cpuid_xlevel2". This won't have any guest-visible effect because no there is no CPUID[0xC0000001] feature supported by TCG, and KVM code will never call cpu_x86_cpuid() with such an index value. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <20170509132736.10071-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-05hax: Fix memory mapping de-duplication logicYu Ning1-2/+17
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: Yu Ning <yu.ning@linux.intel.com> Message-Id: <20170428072723.7036-1-yu.ning@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-05-05target/i386: Add GDB XML register description supportAbdallah Bouassida1-4/+17
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: Abdallah Bouassida <abdallah.bouassida@lauterbach.com> Message-Id: <2b3c8119-1602-28c7-eab4-296593877103@lauterbach.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-10target/i386/misc_helper: wrap BQL around another IRQ generatorAlex Bennée1-0/+3
Anything that calls into HW emulation must be protected by the BQL. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-02target-i386: fix "info lapic" segfault on isapcTejaswini Poluri1-0/+4
Start QEMU with "qemu-system-x86_64 -nographic -M isapc -serial none-monitor stdio" and enter "info lapic" at the monitor prompt ⇒ Segmentation fault Signed-off-by: Tejaswini Poluri <tejaswinipoluri3@gmail.com> Message-Id: <1490685583-16987-1-git-send-email-tejaswinipoluri3@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-31hmp: fix "dump-quest-memory" segfaultIwona Kotlarska1-2/+1
Running QEMU with "qemu-system-x86_64 -M none -nographic -m 256" and executing "dump-guest-memory /dev/null 0 8192" results in segfault. Fix by checking if we have CPU. Signed-off-by: Iwona Kotlarska <iwona260909@gmail.com> Message-Id: <20170330050924.22134-1-iwona260909@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Fixed up title
2017-03-28i386: Don't override -cpu options on -cpu host/maxEduardo Habkost2-4/+11
The existing code for "host" and "max" CPU models overrides every single feature in the CPU object at realize time, even the ones that were explicitly enabled or disabled by the user using "feat=on" or "feat=off", while features set using +feat/-feat are kept. This means "-cpu host,+invtsc" works as expected, while "-cpu host,invtsc=on" doesn't. This was a known bug, already documented in a comment inside x86_cpu_expand_features(). What makes this bug worse now is that libvirt 3.0.0 and newer now use "feat=on|off" instead of +feat/-feat when it detects a QEMU version that supports it (see libvirt commit d47db7b16dd5422c7e487c8c8ee5b181a2f9cd66). Change the feature property getter/setter to set a env->user_features field, to keep track of features that were explicitly changed using QOM properties. Then make the max_features code not override user features when handling "-cpu host" and "-cpu max". This will also allow us to remove the plus_features/minus_features hack in the future, but I plan to do that after 2.9.0 is released. Reported-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-3-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-28i386: Replace uint32_t* with FeatureWord on feature getter/setterEduardo Habkost1-8/+11
Instead of passing a pointer to the feature property getter and setter functions, pass a FeatureWord enum so they can perform other actions related to the feature flag. This will be used to add a new "user_features" field to keep track of features that were explicitly set by the user. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-2-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-24tcg/i386: Check the size of instruction being translatedPranith Kumar1-0/+7
This fixes the bug: 'user-to-root privesc inside VM via bad translation caching' reported by Jann Horn here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1122 Reviewed-by: Richard Henderson <rth@twiddle.net> CC: Peter Maydell <peter.maydell@linaro.org> CC: Paolo Bonzini <pbonzini@redhat.com> Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Message-Id: <20170323175851.14342-1-bobby.prani@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-14kvm: Print MSR information if KVM_{GET,SET}_MSRS failedEduardo Habkost1-0/+12
When a KVM_{GET,SET}_MSRS ioctl() fails, it is difficult to find out which MSR caused the problem. Print an error message for debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs) assert. Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309194634.28457-1-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-13Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into ↵Peter Maydell3-1/+38
staging x86: Haswell TSX blacklist fix for 2.9 # gpg: Signature made Fri 10 Mar 2017 18:45:08 GMT # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-pull-request: i386: Change stepping of Haswell to non-blacklisted value i386/kvm: Blacklist TSX on known broken hosts i386: host_vendor_fms() helper function Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-03-10i386: Change stepping of Haswell to non-blacklisted valueEduardo Habkost1-1/+1
glibc blacklists TSX on Haswell CPUs with model==60 and stepping < 4. To make the Haswell CPU model more useful, make those guests actually use TSX by changing CPU stepping to 4. References: * glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359 https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386/kvm: Blacklist TSX on known broken hostsEduardo Habkost1-0/+17
Some Intel CPUs are known to have a broken TSX implementation. A microcode update from Intel disabled TSX on those CPUs, but GET_SUPPORTED_CPUID might be reporting it as supported if the hosts were not updated yet. Manually fixup the GET_SUPPORTED_CPUID data to ensure we will never enable TSX when running on those hosts. Reference: * glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359: https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386: host_vendor_fms() helper functionEduardo Habkost2-0/+20
Helper function for code that needs to check the host CPU vendor/family/model/stepping values. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-09target-i386: defer VMEXIT to do_interruptPaolo Bonzini3-18/+26
Paths through the softmmu code during code generation now need to be audited to check for double locking of tb_lock. In particular, VMEXIT can take tb_lock through cpu_vmexit -> cpu_x86_update_cr4 -> tlb_flush. To avoid this, split VMEXIT delivery in two parts, similar to what is done with exceptions. cpu_vmexit only records the VMEXIT exit code and information, and cc->do_interrupt can then deliver it when it is safe to take the lock. Reported-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Suggested-by: Richard Henderson <rth@twiddle.net> Tested-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net>
2017-03-09target/i386/cpu.h: declare TCG_GUEST_DEFAULT_MOAlex Bennée1-0/+3
This suppresses the incorrect warning when forcing MTTCG for x86 guests on x86 hosts. A future patch will still warn when TARGET_SUPPORT_MTTCG hasn't been defined for the guest (which is still pending for x86). Reported-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-03x86: Work around SMI migration breakagesDr. David Alan Gilbert3-1/+11
Migration from a 2.3.0 qemu results in a reboot on the receiving QEMU due to a disagreement about SM (System management) interrupts. 2.3.0 didn't have much SMI support, but it did set CPU_INTERRUPT_SMI and this gets into the migration stream, but on 2.3.0 it never got delivered. ~2.4.0 SMI interrupt support was added but was broken - so that when a 2.3.0 stream was received it cleared the CPU_INTERRUPT_SMI but never actually caused an interrupt. The SMI delivery was recently fixed by 68c6efe07a, but the effect now is that an incoming 2.3.0 stream takes the interrupt it had flagged but it's bios can't actually handle it(I think partly due to the original interrupt not being taken during boot?). The consequence is a triple(?) fault and a reboot. Tested from: 2.3.1 -M 2.3.0 2.7.0 -M 2.3.0 2.8.0 -M 2.3.0 2.8.0 -M 2.8.0 This corresponds to RH bugzilla entry 1420679. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170223133441.16010-1-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03qapi: flatten GuestPanicInformation unionAnton Nefedov1-9/+6
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Eric Blake <eblake@redhat.com> Message-Id: <1487614915-18710-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: do not use sigtimedwait to catch SIGBUSPaolo Bonzini1-3/+2
Call kvm_on_sigbus_vcpu asynchronously from the VCPU thread. Information for the SIGBUS can be stored in thread-local variables and processed later in kvm_cpu_exec. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: remove kvm_arch_on_sigbusPaolo Bonzini1-35/+5
Build it on kvm_arch_on_sigbus_vcpu instead. They do the same for "action optional" SIGBUSes, and the main thread should never get "action required" SIGBUSes because it blocks the signal. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03cpus: reorganize signal handling codePaolo Bonzini1-13/+2
Move the KVM "eat signals" code under CONFIG_LINUX, in preparation for moving it to kvm-all.c; reraise non-MCE SIGBUS immediately, without passing it to KVM. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: x86: cleanup SIGBUS handlersPaolo Bonzini1-39/+42
This patch should have no semantic change. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-02Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into ↵Peter Maydell3-80/+385
staging x86 queue, 2017-02-27 "-cpu max" and query-cpu-model-expansion support for x86. This should be the last x86 pull request before 2.9 soft freeze. # gpg: Signature made Mon 27 Feb 2017 16:24:15 GMT # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-pull-request: i386: Improve query-cpu-model-expansion full mode i386: Implement query-cpu-model-expansion QMP command i386: Define static "base" CPU model i386: Don't set CPUClass::cpu_def on "max" model i386: Make "max" model not use any host CPUID info on TCG i386: Create "max" CPU model qapi-schema: Comment about full expansion of non-migration-safe models i386: Reorganize and document CPUID initialization steps i386: Rename X86CPU::host_features to X86CPU::max_features i386: Add ordering field to CPUClass i386: Unset cannot_destroy_with_object_finalize_yet on "host" model Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-27linux-user: Add signal handling support for x86_64Pranith Kumar2-0/+14
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: Allan Wirth <awirth@akamai.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20170226165345.8757-1-bobby.prani@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2017-02-27i386: Improve query-cpu-model-expansion full modeEduardo Habkost1-3/+31
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: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Implement query-cpu-model-expansion QMP commandEduardo Habkost1-1/+190
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: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Define static "base" CPU modelEduardo Habkost2-0/+22
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: David Hildenbrand <david@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-05 07:15:35 +0000