aboutsummaryrefslogtreecommitdiff
path: root/qom/cpu.c
AgeCommit message (Collapse)AuthorFilesLines
2019-06-11qemu-common: Move tcg_enabled() etc. to sysemu/tcg.hMarkus Armbruster1-1/+1
Other accelerators have their own headers: sysemu/hax.h, sysemu/hvf.h, sysemu/kvm.h, sysemu/whpx.h. Only tcg_enabled() & friends sit in qemu-common.h. This necessitates inclusion of qemu-common.h into headers, which is against the rules spelled out in qemu-common.h's file comment. Move tcg_enabled() & friends into their own header sysemu/tcg.h, and adjust #include directives. Cc: Richard Henderson <rth@twiddle.net> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-2-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [Rebased with conflicts resolved automatically, except for accel/tcg/tcg-all.c]
2019-06-10cpu: Move icount_decr to CPUNegativeOffsetStateRichard Henderson1-2/+2
Amusingly, we had already ignored the comment to keep this value at the end of CPUState. This restores the minimum negative offset from TCG_AREG0 for code generation. For the couple of uses within qom/cpu.c, without NEED_CPU_H, add a pointer from the CPUState object to the IcountDecr object within CPUNegativeOffsetState. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-04-18qom/cpu: Simplify how CPUClass:cpu_dump_state() printsMarkus Armbruster1-3/+3
CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-18qom/cpu: Simplify how CPUClass::dump_statistics() printsMarkus Armbruster1-3/+2
CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Its only caller hmp_info_cpustats() (via cpu_dump_statistics()) passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The type-punning is ugly. Drop the callback, and call qemu_printf() instead. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-13-armbru@redhat.com>
2019-03-11qom: cpu: destroy work_mutex in cpu_common_finalizeLi Qiang1-0/+3
Commit 376692b9dc6(cpus: protect work list with work_mutex) initialize a work_mutex in cpu_common_initfn, however forget to destroy it. This will cause resource leak when hotunplug cpu or hotplug cpu fails. Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20190102074114.26988-1-liq3ea@163.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-01-29qom/cpu: Add cluster_index to CPUStatePeter Maydell1-0/+1
For TCG we want to distinguish which cluster a CPU is in, and we need to do it quickly. Cache the cluster index in the CPUState struct, by having the cluster object set cpu->cluster_index for each CPU child when it is realized. This means that board/SoC code must add all CPUs to the cluster before realizing the cluster object. Regrettably QOM provides no way to prevent adding children to a realized object and no way for the parent to be notified when a new child is added to it, so we don't have any way to enforce/assert this constraint; all we can do is document it in a comment. We can at least put in a check that the cluster contains at least one CPU, which should catch the typical cases of "realized cluster too early" or "forgot to parent the CPUs into it". The restriction on how many clusters can exist in the system is imposed by TCG code which will be added in a subsequent commit, but the check to enforce it in cluster.c fits better in this one. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20190121152218.9592-3-peter.maydell@linaro.org
2019-01-07qdev-props: remove errp from GlobalPropertyMarc-André Lureau1-1/+0
All qdev_prop_register_global() set &error_fatal for errp, except '-rtc driftfix=slew', which arguably should also use &error_fatal, as otherwise failing to apply the property would only report a warning. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-18tcg: access cpu->icount_decr.u16.high with atomicsEmilio G. Cota1-1/+1
Consistently access u16.high with atomics to avoid undefined behaviour in MTTCG. Note that icount_decr.u16.low is only used in icount mode, so regular accesses to it are OK. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <20181010144853.13005-2-cota@braap.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-10-17cpu: Provide a proper prototype for target_words_bigendian() in a headerThomas Huth1-1/+0
We've got three places already that provide a prototype for this function in a .c file - that's ugly. Let's provide a proper prototype in a header instead, with a proper description why this function should not be used in most cases. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-03-19cpu: drop unnecessary NULL check and cpu_common_class_by_name()Igor Mammedov1-12/+2
both do nothing as for the first all callers parse_cpu_model() and qmp_query_cpu_model_() should provide non NULL value, so just abort if it's not so. While at it drop cpu_common_class_by_name() which is not need any more as every target has CPUClass::class_by_name callback by now, though abort in case a new arch will forget to define one. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1518013857-4372-1-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-03-19Use cpu_create(type) instead of cpu_init(cpu_model)Igor Mammedov1-43/+4
With all targets defining CPU_RESOLVING_TYPE, refactor cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model) so that callers won't have to know internal resolving cpu type. Place it in exec.c so it could be called from both target independed vl.c and *-user/main.c. That allows us to stop abusing cpu type from MachineClass::default_cpu_type as resolver class in vl.c which were confusing part of cpu_parse_cpu_model(). Also with new parse_cpu_model(), the last users of cpu_init() in null-machine.c and bsd/linux-user targets could be switched to cpu_create() API and cpu_init() API will be removed by follow up patch. With no longer users left remove MachineState::cpu_model field, new code should use MachineState::cpu_type instead and leave cpu_model parsing to generic code in vl.c. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1518000027-274608-5-git-send-email-imammedo@redhat.com> [ehabkost: Fix bsd-user build error] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-10-24tcg: Add CPUState cflags_next_tbRichard Henderson1-0/+1
We were generating code during tb_invalidate_phys_page_range, check_watchpoint, cpu_io_recompile, and (seemingly) discarding the TB, assuming that it would magically be picked up during the next iteration through the cpu_exec loop. Instead, record the desired cflags in CPUState so that we request the proper TB so that there is no more magic. Reviewed-by: Emilio G. Cota <cota@braap.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2017-10-09qom/cpu: move cpu_model null check to cpu_class_by_name()Philippe Mathieu-Daudé1-1/+6
and clean every implementation. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20170917232842.14544-1-f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-09-19cpu: make cpu_generic_init() abort QEMU on errorIgor Mammedov1-14/+5
Almost every user of cpu_generic_init() checks for returned NULL and then reports failure in a custom way and aborts process. Some users assume that call can't fail and don't check for failure, though they should have checked for it. In either cases cpu_generic_init() failure is fatal, so instead of checking for failure and reporting it various ways, make cpu_generic_init() report errors in consistent way and terminate QEMU on failure. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1505318697-77161-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-09-19qom: cpus: split cpu_generic_init() on feature parsing and cpu creation partsIgor Mammedov1-16/+30
it would allow to reuse feature parsing part in various machines that have CPU features instead of re-implementing the same feature parsing each time. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1505318697-77161-2-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-09-07boards.h: Define new flag ignore_memory_transaction_failuresPeter Maydell1-0/+16
Define a new MachineClass field ignore_memory_transaction_failures. If this is flag is true then the CPU will ignore memory transaction failures which should cause the CPU to take an exception due to an access to an unassigned physical address; the transaction will instead return zero (for a read) or be ignored (for a write). This should be set only by legacy board models which rely on the old RAZ/WI behaviour for handling devices that QEMU does not yet model. New board models should instead use "unimplemented-device" for all memory ranges where the guest will attempt to probe for a device that QEMU doesn't implement and a stub device is required. We need this for ARM boards, where we're about to implement support for generating external aborts on memory transaction failures. Too many of our legacy board models rely on the RAZ/WI behaviour and we would break currently working guests when their "probe for device" code provoked an external abort rather than a RAZ. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Message-id: 1504626814-23124-2-git-send-email-peter.maydell@linaro.org
2017-09-01qom: cpu: fix parsed feature string lengthIgor Mammedov1-8/+6
since commit ( 9262685b cpu: Factor out cpu_generic_init() ) features parsed by it were truncated only to the 1st feature after CPU name due to fact that featurestr = strtok(NULL, ","); cc->parse_features(cpu, featurestr, &err); would extract exactly one feature and parse_features() callback would parse it and only it leaving the rest of features ignored. Reuse approach from x86 custom impl. i.e. replace strtok() token parsing with g_strsplit(), which would split feature string in 2 parts name and features list and pass the later to parse_features() callback. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1503592308-93913-2-git-send-email-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-09-01cpu: cpu_by_arch_id() helperEduardo Habkost1-3/+8
The helper can be used for CPU object lookup using the CPU's arch-specific ID (the one returned by CPUClass::get_arch_id()). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [Yi Wang: Added documentation comments] Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Yun Liu <liu.yunh@zte.com.cn> [ehabkost: extracted cpu_by_arch_id() to a separate patch] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-08-09Revert "cpu: add APIs to allocate/free CPU environment"Michael S. Tsirkin1-34/+0
This reverts commit e2a7f28693aea7e194ec1435697ec4feb24f8a6f. This was not supposed to go upstream yet. Reverting. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-08-08cpu: add APIs to allocate/free CPU environmentMichael S. Tsirkin1-0/+34
These will be implemented and then used by follow-up patches. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-17trace: Allocate cpu->trace_dstate in placeLluís Vilanova1-8/+0
There's little point in dynamically allocating the bitmap if we know at compile-time the max number of events we want to support. Thus, make room in the struct for the bitmap, which will make things easier later: this paves the way for upcoming changes, in which we'll use a u32 to fully capture cpu->trace_dstate. This change also increases performance by saving a dereference and improving locality--note that this is important since upcoming work makes reading this bitmap fairly common. Signed-off-by: Emilio G. Cota <cota@braap.org> Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 149915725977.6295.15069969323605305641.stgit@frigg.lan Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-07-14cpu: Convert to DEFINE_PROP_LINKFam Zheng1-0/+1
Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170714021509.23681-20-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-04cpu: move interrupt handling out of translate-common.cPaolo Bonzini1-0/+13
translate-common.c will not be available anymore with --disable-tcg, so we cannot leave cpu_interrupt_handler there. Move the TCG-specific handler to accel/tcg/tcg-all.c, and adopt KVM's handler as the default one, since it works just as well for Xen and qtest. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-04cpu: Introduce a wrapper for tlb_flush() that can be used in common codeThomas Huth1-3/+2
Commit 1f5c00cfdb8114c ("qom/cpu: move tlb_flush to cpu_common_reset") moved the call to tlb_flush() from the target-specific reset handlers into the common code qom/cpu.c file, and protected the call with "#ifdef CONFIG_SOFTMMU" to avoid that it is called for linux-user only targets. But since qom/cpu.c is common code, CONFIG_SOFTMMU is *never* defined here, so the tlb_flush() was simply never executed anymore. Fix it by introducing a wrapper for tlb_flush() in a file that is re-compiled for each target, i.e. in translate-all.c. Fixes: 1f5c00cfdb8114c1e3a13426588ceb64f82c9ddb Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1498454578-18709-5-git-send-email-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-30tcg: consistently access cpu->tb_jmp_cache atomicallyEmilio G. Cota1-4/+1
Some code paths can lead to atomic accesses racing with memset() on cpu->tb_jmp_cache, which can result in torn reads/writes and is undefined behaviour in C11. These torn accesses are unlikely to show up as bugs, but from code inspection they seem possible. For example, tb_phys_invalidate does: /* remove the TB from the hash list */ h = tb_jmp_cache_hash_func(tb->pc); CPU_FOREACH(cpu) { if (atomic_read(&cpu->tb_jmp_cache[h]) == tb) { atomic_set(&cpu->tb_jmp_cache[h], NULL); } } Here atomic_set might race with a concurrent memset (such as the ones scheduled via "unsafe" async work, e.g. tlb_flush_page) and therefore we might end up with a torn pointer (or who knows what, because we are under undefined behaviour). This patch converts parallel accesses to cpu->tb_jmp_cache to use atomic primitives, thereby bringing these accesses back to defined behaviour. The price to pay is to potentially execute more instructions when clearing cpu->tb_jmp_cache, but given how infrequently they happen and the small size of the cache, the performance impact I have measured is within noise range when booting debian-arm. Note that under "safe async" work (e.g. do_tb_flush) we could use memset because no other vcpus are running. However I'm keeping these accesses atomic as well to keep things simple and to avoid confusing analysis tools such as ThreadSanitizer. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1497486973-25845-1-git-send-email-cota@braap.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
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-12trace: add sanity checkAnthony Xu1-1/+5
If trace backend is set to TRACE_NOP, trace_get_vcpu_event_count returns 0, cause bitmap_new call abort. The abort can be triggered as follows: $ ./configure --enable-trace-backend=nop --target-list=x86_64-softmmu $ gdb ./x86_64-softmmu/qemu-system-x86_64 -M q35,accel=kvm -m 1G (gdb) bt #0 0x00007ffff04e25f7 in raise () from /lib64/libc.so.6 #1 0x00007ffff04e3ce8 in abort () from /lib64/libc.so.6 #2 0x00005555559de905 in bitmap_new (nbits=<optimized out>) at /home/root/git/qemu2.git/include/qemu/bitmap.h:96 #3 cpu_common_initfn (obj=0x555556621d30) at qom/cpu.c:399 #4 0x0000555555a11869 in object_init_with_type (obj=0x555556621d30, ti=0x55555656bbb0) at qom/object.c:341 #5 0x0000555555a11869 in object_init_with_type (obj=0x555556621d30, ti=0x55555656bd30) at qom/object.c:341 #6 0x0000555555a11efc in object_initialize_with_type (data=data@entry=0x555556621d30, size=76560, type=type@entry=0x55555656bd30) at qom/object.c:376 #7 0x0000555555a12061 in object_new_with_type (type=0x55555656bd30) at qom/object.c:484 #8 0x0000555555a121c5 in object_new (typename=typename@entry=0x555556550340 "qemu64-x86_64-cpu") at qom/object.c:494 #9 0x00005555557f6e3d in pc_new_cpu (typename=typename@entry=0x555556550340 "qemu64-x86_64-cpu", apic_id=0, errp=errp@entry=0x5555565391b0 <error_fatal>) at /home/root/git/qemu2.git/hw/i386/pc.c:1101 #10 0x00005555557fa33e in pc_cpus_init (pcms=pcms@entry=0x5555565f9690) at /home/root/git/qemu2.git/hw/i386/pc.c:1184 #11 0x00005555557fe0f6 in pc_q35_init (machine=0x5555565f9690) at /home/root/git/qemu2.git/hw/i386/pc_q35.c:121 #12 0x000055555574fbad in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4562 Signed-off-by: Anthony Xu <anthony.xu@intel.com> Message-id: 1494369432-15418-1-git-send-email-anthony.xu@intel.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-03-03Merge branch 'icount-update' into HEADPaolo Bonzini1-1/+1
Merge the original development branch due to breakage caused by the MTTCG merge. Conflicts: cpu-exec.c translate-common.c Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-24tcg: drop global lock during TCG code executionJan Kiszka1-0/+10
This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when entering MMIO or PIO emulation, or when leaving the TCG loop. We have to revert a few optimization for the current TCG threading model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not kicking it in qemu_cpu_kick. We also need to disable RAM block reordering until we have a more efficient locking mechanism at hand. Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. These numbers demonstrate where we gain something: 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm The guest CPU was fully loaded, but the iothread could still run mostly independent on a second core. Without the patch we don't get beyond 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm We don't benefit significantly, though, when the guest is not fully loading a host CPU. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com> [FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex] Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> [EGC: fixed iothread lock for cpu-exec IRQ handling] Signed-off-by: Emilio G. Cota <cota@braap.org> [AJB: -smp single-threaded fix, clean commit msg, BQL fixes] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Pranith Kumar <bobby.prani@gmail.com> [PM: target-arm changes] Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-22cpu-exec: unify icount_decr and tcg_exit_reqPaolo Bonzini1-1/+1
The icount interrupt flag and tcg_exit_req serve almost the same purpose, let's make them completely the same. The former TB_EXIT_REQUESTED and TB_EXIT_ICOUNT_EXPIRED cases are unified, since we can distinguish them from the value of the interrupt flag. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-16report guest crash information in GUEST_PANICKED eventAnton Nefedov1-0/+11
it's not very convenient to use the crash-information property interface, so provide a CPU class callback to get the guest crash information, and pass that information in the event Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-07arm: Correctly handle watchpoints for BE32 CPUsJulian Brown1-0/+6
In BE32 mode, sub-word size watchpoints can fail to trigger because the address of the access is adjusted in the opcode helpers before being compared with the watchpoint registers. This patch reverses the address adjustment before performing the comparison with the help of a new CPUClass hook. This version of the patch augments and tidies up comments a little. Signed-off-by: Julian Brown <julian@codesourcery.com> Message-id: caaf64ffc72f6ae183015337b7afdbd4b8989cb6.1484929304.git.julian@codesourcery.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-31trace: switch to modular code generation for sub-directoriesDaniel P. Berrange1-1/+1
Introduce rules in the top level Makefile that are able to generate trace.[ch] files in every subdirectory which has a trace-events file. The top level directory is handled specially, so instead of creating trace.h, it creates trace-root.h. This allows sub-directories to include the top level trace-root.h file, without ambiguity wrt to the trace.g file in the current sub-dir. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170125161417.31949-7-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-27Introduce DEVICE_CATEGORY_CPU for CPU devicesThomas Huth1-0/+1
Now that CPUs show up in the help text of "-device ?", we should group them into an appropriate category. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1484917276-7107-1-git-send-email-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-20Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-1/+1
* QOM interface fix (Eduardo) * RTC fixes (Gaohuai, Igor) * Memory leak fixes (Li Qiang, me) * Ctrl-a b regression (Marc-André) * Stubs cleanups and fixes (Leif, me) * hxtool tweak (me) * HAX support (Vincent) * QemuThread, exec.c and SCSI fixes (Roman, Xinhua, me) * PC_COMPAT_2_8 fix (Marcelo) * stronger bitmap assertions (Peter) # gpg: Signature made Fri 20 Jan 2017 12:49:01 GMT # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (35 commits) pc.h: move x-mach-use-reliable-get-clock compat entry to PC_COMPAT_2_8 bitmap: assert that start and nr are non negative Revert "win32: don't run subprocess tests on Mingw32 platform" hax: add Darwin support Plumb the HAXM-based hardware acceleration support target/i386: Add Intel HAX files kvm: move cpu synchronization code KVM: PPC: eliminate unnecessary duplicate constants ramblock-notifier: new char: fix ctrl-a b not working exec: Add missing rcu_read_unlock x86: ioapic: fix fail migration when irqchip=split x86: ioapic: dump version for "info ioapic" x86: ioapic: add traces for ioapic hxtool: emit Texinfo headings as @subsection qemu-thread: fix qemu_thread_set_name() race in qemu_thread_create() serial: fix memory leak in serial exit scsi-block: fix direction of BYTCHK test for VERIFY commands pc: fix crash in rtc_set_memory() if initial cpu is marked as hotplugged acpi: filter based on CONFIG_ACPI_X86 rather than TARGET ... # Conflicts: # include/hw/i386/pc.h
2017-01-19kvm: move cpu synchronization codeVincent Palatin1-1/+1
Move the generic cpu_synchronize_ functions to the common hw_accel.h header, in order to prepare for the addition of a second hardware accelerator. Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Message-Id: <f5c3cffe8d520011df1c2e5437bb814989b48332.1484045952.git.vpalatin@chromium.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-17Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' ↵Peter Maydell1-0/+2
into staging # gpg: Signature made Mon 16 Jan 2017 13:44:46 GMT # gpg: using RSA key 0x9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/tracing-pull-request: trace: Add event "guest_cpu_exit" trace: Fix dynamic event state on vCPU hot-unplug trace: Lock vCPU list when initializing dynamic tracing state trace-events: spelling fix Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-16trace: Fix dynamic event state on vCPU hot-unplugLluís Vilanova1-0/+2
We need to disable per-vCPU events on a vCPU that is hot-unplugged to keep the dynamic event state global counters consistent. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 148278748055.1404.1570530281528619895.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-13cpu_common_reset: wrap TCG specific code in tcg_enabled()Alex Bennée1-4/+6
Both the cpu->tb_jmp_cache and SoftMMU TLB structures are only used when running TCG code so we might as well skip them for anything else. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-13qom/cpu: move tlb_flush to cpu_common_resetAlex Bennée1-0/+4
It is a common thing amongst the various cpu reset functions want to flush the SoftMMU's TLB entries. This is done either by calling tlb_flush directly or by way of a general memset of the CPU structure (sometimes both). This moves the tlb_flush call to the common reset function and additionally ensures it is only done for the CONFIG_SOFTMMU case and when tcg is enabled. In some target cases we add an empty end_of_reset_fields structure to the target vCPU structure so have a clear end point for any memset which is resetting value in the structure before CPU_COMMON (where the TLB structures are). While this is a nice clean-up in general it is also a precursor for changes coming to cputlb for MTTCG where the clearing of entries can't be done arbitrarily across vCPUs. Currently the cpu_reset function is usually called from the context of another vCPU as the architectural power up sequence is run. By using the cputlb API functions we can ensure the right behaviour in the future. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-24exec: call cpu_exec_exit() from a CPU unrealize common functionLaurent Vivier1-1/+7
As cpu_exec_exit() mirrors the cpu_exec_realizefn(), rename it as cpu_exec_unrealizefn(). Create and register a cpu_common_unrealizefn() function for the CPU device class and call cpu_exec_unrealizefn() from this function. Remove cpu_exec_exit() from cpu_common_finalize() (which mirrors init, not realize), and as x86_cpu_unrealizefn() and ppc_cpu_unrealizefn() overwrite the device class unrealize function, add a call to a parent_unrealize pointer. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-10-24exec: split cpu_exec_init()Laurent Vivier1-0/+2
Put in cpu_exec_initfn() what initializes the CPU, and leave in cpu_exec_init() what adds it to the environment. As cpu_exec_initfn() is called by all XX_cpu_initfn(), call it directly in cpu_common_initfn(). cpu_exec_init() is now a realize function, it will be renamed to cpu_exec_realizefn() and moved to the XX_cpu_realizefn() function in a following patch. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-10-12trace: dynamically allocate trace_dstate in CPUStateDaniel P. Berrange1-2/+5
The CPUState struct has a bitmap tracking which VCPU events are currently active. This is indexed based on the event ID values, and sized according the maximum TraceEventVCPUID enum value. When we start dynamically assigning IDs at runtime, we can't statically declare a bitmap without making an assumption about the max event count. This problem can be solved by dynamically allocating the per-CPU dstate bitmap. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475588159-30598-15-git-send-email-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-04cpu: atomically modify cpu->exit_requestAlex Bennée1-2/+2
ThreadSanitizer picks up potential races although we already use barriers to ensure things are in the correct order when processing exit requests. For true C11 defined behaviour across threads we need to use relaxed atomic_set/atomic_read semantics to reassure tsan. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20160930213106.20186-9-alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-04qom/cpu: atomically clear the tb_jmp_cacheAlex Bennée1-1/+5
The ThreadSanitizer rightly complains that something initialised with a normal access is later updated and read atomically. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20160930213106.20186-8-alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-28trace: Add event "guest_cpu_reset"Lluís Vilanova1-0/+3
Signals the reset of the state a virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428971851.15111.8799439252178273840.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-28trace: Properly initialize dynamic event states in hot-plugged vCPUsLluís Vilanova1-0/+3
Every time a vCPU is hot-plugged, it will "inherit" its tracing state from the global state array. That is, if *any* existing vCPU has an event enabled, new vCPUs will have too. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428970768.15111.7664565956870423529.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-19linux-user-i386: Fix crash on cpuidMarc-André Lureau1-0/+5
Running cpuid instructions with a simple run like: i386-linux-user/qemu-i386 tests/tcg/sha1-i386 Results in the following assert: #0 0x00007ffff64246f5 in raise () from /lib64/libc.so.6 #1 0x00007ffff64262fa in abort () from /lib64/libc.so.6 #2 0x00007ffff7937ec5 in g_assertion_message () from /lib64/libglib-2.0.so.0 #3 0x00007ffff7937f5a in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 #4 0x000055555561b54c in apicid_bitwidth_for_count (count=0) at /home/elmarco/src/qemu/include/hw/i386/topology.h:58 #5 0x000055555561b58a in apicid_smt_width (nr_cores=0, nr_threads=0) at /home/elmarco/src/qemu/include/hw/i386/topology.h:67 #6 0x000055555561b5c3 in apicid_core_offset (nr_cores=0, nr_threads=0) at /home/elmarco/src/qemu/include/hw/i386/topology.h:82 #7 0x000055555561b5e3 in apicid_pkg_offset (nr_cores=0, nr_threads=0) at /home/elmarco/src/qemu/include/hw/i386/topology.h:89 #8 0x000055555561dd86 in cpu_x86_cpuid (env=0x555557999550, index=4, count=3, eax=0x7fffffffcae8, ebx=0x7fffffffcaec, ecx=0x7fffffffcaf0, edx=0x7fffffffcaf4) at /home/elmarco/src/qemu/target-i386/cpu.c:2405 #9 0x0000555555638e8e in helper_cpuid (env=0x555557999550) at /home/elmarco/src/qemu/target-i386/misc_helper.c:106 #10 0x000055555599dc5e in static_code_gen_buffer () #11 0x00005555555952f8 in cpu_tb_exec (cpu=0x5555579912d0, itb=0x7ffff4371ab0) at /home/elmarco/src/qemu/cpu-exec.c:166 #12 0x0000555555595c8e in cpu_loop_exec_tb (cpu=0x5555579912d0, tb=0x7ffff4371ab0, last_tb=0x7fffffffd088, tb_exit=0x7fffffffd084, sc=0x7fffffffd0a0) at /home/elmarco/src/qemu/cpu-exec.c:517 #13 0x0000555555595e50 in cpu_exec (cpu=0x5555579912d0) at /home/elmarco/src/qemu/cpu-exec.c:612 #14 0x00005555555c065b in cpu_loop (env=0x555557999550) at /home/elmarco/src/qemu/linux-user/main.c:297 #15 0x00005555555c25b2 in main (argc=2, argv=0x7fffffffd848, envp=0x7fffffffd860) at /home/elmarco/src/qemu/linux-user/main.c:4803 The fields are set in qemu_init_vcpu() with softmmu, but it's a stub with linux-user. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-26exec: Set cpu_index only if it's not been explictly setIgor Mammedov1-1/+1
It keeps the legacy behavior for all users that doesn't care about stable cpu_index value, but would allow boards that would support device_add/device_del to set stable cpu_index that won't depend on order in which cpus are created/destroyed. While at that simplify cpu_get_free_index() as cpu_index generated by USER_ONLY and softmmu variants is the same since none of the users support cpu-remove so far, except of not yet released spapr/x86 device_add/delr, which will be altered by follow up patches to set stable cpu_index manually. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-18trace: Add per-vCPU tracing states for events with the 'vcpu' propertyLluís Vilanova1-0/+1
Each vCPU gets a 'trace_dstate' bitmap to control the per-vCPU dynamic tracing state of events with the 'vcpu' property. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
generated by cgit v1.1 at 2024-12-27 20:47:20 +0000