cde0a63a | 23-Jun-2017 |
Michael S. Tsirkin <mst@redhat.com> |
Revert "cpu: add APIs to allocate/free CPU environment"
This reverts commit e2a7f28693aea7e194ec1435697ec4feb24f8a6f.
This was not supposed to go upstream yet. Reverting.
Signed-off-by: Michael S.
Revert "cpu: add APIs to allocate/free CPU environment"
This reverts commit e2a7f28693aea7e194ec1435697ec4feb24f8a6f.
This was not supposed to go upstream yet. Reverting.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
e2a7f286 | 23-Jun-2017 |
Michael S. Tsirkin <mst@redhat.com> |
cpu: add APIs to allocate/free CPU environment
These will be implemented and then used by follow-up patches.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> |
87e0331c | 28-Jul-2017 |
Philippe Mathieu-Daudé <f4bug@amsat.org> |
docs: fix broken paths to docs/devel/tracing.txt
With the move of some docs/ to docs/devel/ on ac06724a71, no references were updated.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Review
docs: fix broken paths to docs/devel/tracing.txt
With the move of some docs/ to docs/devel/ on ac06724a71, no references were updated.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
368e708b | 18-Jul-2017 |
Peter Maydell <peter.maydell@linaro.org> |
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging
x86 and machine queue, 2017-07-17
# gpg: Signature made Mon 17 Jul 2017 19:46:14 BST # gpg:
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging
x86 and machine queue, 2017-07-17
# gpg: Signature made Mon 17 Jul 2017 19:46:14 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: qmp: Include parent type on 'qom-list-types' output qmp: Include 'abstract' field on 'qom-list-types' output tests: Simplify abstract-interfaces check with a helper i386: add Skylake-Server cpu model i386: Update comment about XSAVES on Skylake-Client i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf fw_cfg: move QOM type defines and fw_cfg types into fw_cfg.h fw_cfg: move qdev_init_nofail() from fw_cfg_init1() to callers fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path qom: Fix ambiguous path detection when ambiguous=NULL Revert "machine: Convert abstract typename on compat_props to subclass names" test-qdev-global-props: Test global property ordering qdev: fix the order compat and global properties are applied tests: Test case for object_resolve_path*() device-crash-test: Fix regexp on whitelist
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
ebcc479e | 07-Jul-2017 |
Eduardo Habkost <ehabkost@redhat.com> |
qom: Fix ambiguous path detection when ambiguous=NULL
object_resolve_path*() ambiguous path detection breaks when ambiguous==NULL and the object tree have 3 objects of the same type and only 2 of th
qom: Fix ambiguous path detection when ambiguous=NULL
object_resolve_path*() ambiguous path detection breaks when ambiguous==NULL and the object tree have 3 objects of the same type and only 2 of them are under the same parent. e.g.:
/container/obj1 (TYPE_FOO) /container/obj2 (TYPE_FOO) /obj2 (TYPE_FOO)
With the above tree, object_resolve_path_type("", TYPE_FOO, NULL) will incorrectly return /obj2, because the search inside "/container" will return NULL, and the match at "/obj2" won't be detected as ambiguous.
Fix that by always calling object_resolve_partial_path() with a non-NULL ambiguous parameter.
Test case included.
Reported-by: Igor Mammedov <imammedo@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170707213052.13087-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
d01c05c9 | 04-Jul-2017 |
Lluís Vilanova <vilanova@ac.upc.edu> |
trace: Allocate cpu->trace_dstate in place
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 st
trace: Allocate cpu->trace_dstate in place
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>
show more ...
|
c7e002c5 | 13-Jul-2017 |
Fam Zheng <famz@redhat.com> |
cpu: Convert to DEFINE_PROP_LINK
Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170714021509.23681-20-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
8f5d58ef | 13-Jul-2017 |
Igor Mammedov <imammedo@redhat.com> |
qom: enforce readonly nature of link's check callback
link's check callback is supposed to verify/permit setting it, however currently nothing restricts it from misusing it and modifying target obje
qom: enforce readonly nature of link's check callback
link's check callback is supposed to verify/permit setting it, however currently nothing restricts it from misusing it and modifying target object from within. Make sure that readonly semantics are checked by compiler to prevent callback's misuse.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170714021509.23681-2-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
290dae46 | 04-Jul-2017 |
Paolo Bonzini <pbonzini@redhat.com> |
cpu: move interrupt handling out of translate-common.c
translate-common.c will not be available anymore with --disable-tcg, so we cannot leave cpu_interrupt_handler there.
Move the TCG-specific han
cpu: move interrupt handling out of translate-common.c
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>
show more ...
|
2cd53943 | 26-Jun-2017 |
Thomas Huth <thuth@redhat.com> |
cpu: Introduce a wrapper for tlb_flush() that can be used in common code
Commit 1f5c00cfdb8114c ("qom/cpu: move tlb_flush to cpu_common_reset") moved the call to tlb_flush() from the target-specific
cpu: Introduce a wrapper for tlb_flush() that can be used in common code
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>
show more ...
|
f3ced3c5 | 14-Jun-2017 |
Emilio G. Cota <cota@braap.org> |
tcg: consistently access cpu->tb_jmp_cache atomically
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 be
tcg: consistently access cpu->tb_jmp_cache atomically
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>
show more ...
|
3152779c | 07-Jun-2017 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
object: add uint property setter/getter
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170607163635.17635-13-marcand
object: add uint property setter/getter
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170607163635.17635-13-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
01b2ffce | 07-Jun-2017 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
qapi: merge QInt and QFloat in QNum
We would like to use a same QObject type to represent numbers, whether they are int, uint, or floats. Getters will allow some compatibility between the various ty
qapi: merge QInt and QFloat in QNum
We would like to use a same QObject type to represent numbers, whether they are int, uint, or floats. Getters will allow some compatibility between the various types if the number fits other representations.
Add a few more tests while at it.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170607163635.17635-7-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [parse_stats_intervals() simplified a bit, comment in test_visitor_in_int_overflow() tidied up, suppress bogus warnings] Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
560f19f1 | 07-Jun-2017 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
object: fix potential leak in getters
If the property is not of the requested type, the getters will leak a QObject.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric
object: fix potential leak in getters
If the property is not of the requested type, the getters will leak a QObject.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170607163635.17635-3-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
c645d5ac | 03-Jun-2017 |
Michael Roth <mdroth@linux.vnet.ibm.com> |
monitor: fix object_del for command-line-created objects
Currently objects specified on the command-line are only partially cleaned up when 'object_del' is issued in either HMP or QMP: the object it
monitor: fix object_del for command-line-created objects
Currently objects specified on the command-line are only partially cleaned up when 'object_del' is issued in either HMP or QMP: the object itself is fully finalized, but the QemuOpts are not removed. This results in the following behavior:
x86_64-softmmu/qemu-system-x86_64 -monitor stdio \ -object memory-backend-ram,id=ram1,size=256M
QEMU 2.7.91 monitor - type 'help' for more information (qemu) object_del ram1 (qemu) object_del ram1 object 'ram1' not found (qemu) object_add memory-backend-ram,id=ram1,size=256M Duplicate ID 'ram1' for object Try "help object_add" for more information
which can be an issue for use-cases like memory hotplug.
This happens on the HMP side because hmp_object_add() attempts to create a temporary QemuOpts entry with ID 'ram1', which ends up conflicting with the command-line-created entry, since it was never cleaned up during the previous hmp_object_del() call.
We address this by adding a check in user_creatable_del(), which is called by both qmp_object_del() and hmp_object_del() to handle the actual object cleanup, to determine whether an option group entry matching the object's ID is present and removing it if it is.
Note that qmp_object_add() never attempts to create a temporary QemuOpts entry, so it does not encounter the duplicate ID error, which is why this isn't generally visible in libvirt.
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Daniel Berrange <berrange@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1496531612-22166-3-git-send-email-mdroth@linux.vnet.ibm.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
e90f2a8c | 03-May-2017 |
Eduardo Habkost <ehabkost@redhat.com> |
qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user.
qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable
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>
show more ...
|
5651743c | 09-May-2017 |
Anthony Xu <anthony.xu@intel.com> |
trace: add sanity check
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-tra
trace: add sanity check
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>
show more ...
|
f8df5f92 | 14-Dec-2016 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
container: don't leak container reference
object_property_add_child() references the child, unref it after to avoid ref leaks.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewe
container: don't leak container reference
object_property_add_child() references the child, unref it after to avoid ref leaks.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
08329701 | 23-Mar-2017 |
Eric Blake <eblake@redhat.com> |
qom: Fix regression with 'qom-type'
Commit 9a6d1ac assumed that 'qom-type' could be removed from QemuOpts with no ill effects. However, this command line proves otherwise:
$ ./x86_64-softmmu/qemu-
qom: Fix regression with 'qom-type'
Commit 9a6d1ac assumed that 'qom-type' could be removed from QemuOpts with no ill effects. However, this command line proves otherwise:
$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 qemu-system-x86_64: -object rng-random,filename=/dev/urandom,id=rng0: Parameter 'qom-type' is missing
Fix the regression by restoring qom-type in opts after its temporary removal that was needed for the duration of user_creatable_add_opts().
Reported-by: Richard W. M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Message-id: 20170323160315.19696-1-eblake@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
9a6d1acb | 22-Mar-2017 |
Eric Blake <eblake@redhat.com> |
qom: Avoid unvisited 'id'/'qom-type' in user_creatable_add_opts
A regression in commit 15c2f669e caused us to silently ignore excess input to the QemuOpts visitor. Later, commit ea4641 accidentally
qom: Avoid unvisited 'id'/'qom-type' in user_creatable_add_opts
A regression in commit 15c2f669e caused us to silently ignore excess input to the QemuOpts visitor. Later, commit ea4641 accidentally abused that situation, by removing "qom-type" and "id" from the corresponding QDict but leaving them defined in the QemuOpts, when using the pair of containers to create a user-defined object. Note that since we are already traversing two separate items (a QDict and a QemuOpts), we are already able to flag bogus arguments, as in:
$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio -object memory-backend-ram,id=mem1,size=4k,bogus=huh qemu-system-x86_64: -object memory-backend-ram,id=mem1,size=4k,bogus=huh: Property '.bogus' not found
So the only real concern is that when we re-enable strict checking in the QemuOpts visitor, we do not want to start flagging the two leftover keys as unvisited. Rearrange the code to clean out the QemuOpts listing in advance, rather than removing items from the QDict. Since "qom-type" is usually an automatic implicit default, we don't have to restore it (this does mean that once instantiated, QemuOpts is not necessarily an accurate representation of the original command line - but this is not the first place to do that); however "id" has to be put back (requiring us to cast away a const).
[As a side note, hmp_object_add() turns a QDict into a QemuOpts, then calls user_creatable_add_opts() which converts QemuOpts into a new QDict. There are probably a lot of wasteful conversions like this, but cleaning them up is a much bigger task than the immediate regression fix.]
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20170322144525.18964-3-eblake@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
048abb7b | 03-Mar-2017 |
Markus Armbruster <armbru@redhat.com> |
qapi: Drop unused non-strict qobject input visitor
The split between tests/test-qobject-input-visitor.c and tests/test-qobject-input-strict.c now makes less sense than ever. The next commit will ta
qapi: Drop unused non-strict qobject input visitor
The split between tests/test-qobject-input-visitor.c and tests/test-qobject-input-strict.c now makes less sense than ever. The next commit will take care of that.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1488544368-30622-20-git-send-email-armbru@redhat.com>
show more ...
|
05601ed2 | 03-Mar-2017 |
Markus Armbruster <armbru@redhat.com> |
qom: Make object_property_set_qobject()'s input visitor strict
Commit 240f64b made all qobject input visitors created outside tests strict, except for the one in object_property_set_qobject(). That
qom: Make object_property_set_qobject()'s input visitor strict
Commit 240f64b made all qobject input visitors created outside tests strict, except for the one in object_property_set_qobject(). That one was left behind only because Eric couldn't spare the time to figure out whether making it strict would break anything, with a TODO comment. Time to resolve it.
Strict makes a difference only for otherwise successful visits of QAPI structs or unions. Let's examine what the callers of object_property_set_qobject() visit:
* object_property_set_str(), object_property_set_bool(), object_property_set_int() visit a QString, QBool, QInt, respectively. Strictness can't matter.
* qmp_qom_set visits its @value argument. Comes straight from QMP and can be anything ('any' in the QAPI schema). Strictness matters when the property's set() method visits a struct or union QAPI type.
No such methods exist, thus switching to strict can't break anything.
If we acquire such methods in the future, we'll *want* the visitor to be strict, so that unexpected members get rejected as they should be.
Switch to strict.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1488544368-30622-18-git-send-email-armbru@redhat.com>
show more ...
|
30f3dda2 | 03-Mar-2017 |
Paolo Bonzini <pbonzini@redhat.com> |
Merge branch 'icount-update' into HEAD
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 <pbo
Merge branch 'icount-update' into HEAD
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>
show more ...
|
8d04fb55 | 23-Feb-2017 |
Jan Kiszka <jan.kiszka@siemens.com> |
tcg: drop global lock during TCG code execution
This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when ente
tcg: drop global lock during TCG code execution
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>
show more ...
|
1aab16c2 | 27-Jan-2017 |
Paolo Bonzini <pbonzini@redhat.com> |
cpu-exec: unify icount_decr and tcg_exit_req
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_
cpu-exec: unify icount_decr and tcg_exit_req
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>
show more ...
|