aboutsummaryrefslogtreecommitdiff
path: root/accel/accel.c
AgeCommit message (Collapse)AuthorFilesLines
2019-05-02accel: Remove unused AccelClass::available fieldEduardo Habkost1-5/+0
The field is not used anymore, we can remove it. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190422210448.2488-4-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> [on mingw64] Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-04-02accel: Unbreak accelerator fallbackMarkus Armbruster1-1/+2
When the user specifies a list of accelerators, we pick the first one that initializes successfully. Recent commit 1a3ec8c1564 broke that. Reproducer: $ qemu-system-x86_64 --machine accel=xen:tcg xencall: error: Could not obtain handle on privileged command interface: No such file or directory xen be core: xen be core: can't open xen interface can't open xen interface qemu-system-x86_64: failed to initialize Xen: Operation not permitted qemu-system-x86_64: /home/armbru/work/qemu/qom/object.c:436: object_set_accelerator_compat_props: Assertion `!object_compat_props[0]' failed. Root cause: we register accelerator compat properties even when the accelerator fails. The failed assertion is object_set_accelerator_compat_props() telling us off. Fix by calling it only for the accelerator that succeeded. Fixes: 1a3ec8c1564f51628cce10d435a2e22559ea29fd Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20190401090827.20793-6-armbru@redhat.com>
2019-03-11qdev: Fix latent bug with compat_props and onboard devicesMarkus Armbruster1-0/+1
Compatibility properties started life as a qdev property thing: we supported them only for qdev properties, and implemented them with the machinery backing command line option -global. Recent commit fa0cb34d221 put them to use (tacitly) with memory backend objects (subtypes of TYPE_MEMORY_BACKEND). To make that possible, we first moved the work of applying them from the -global machinery into TYPE_DEVICE's .instance_post_init() method device_post_init(), in commits ea9ce8934c5 and b66bbee39f6, then made it available to TYPE_MEMORY_BACKEND's .instance_post_init() method host_memory_backend_post_init() as object_apply_compat_props(), in commit 1c3994f6d2a. Note the code smell: we now have function name starting with object_ in hw/core/qdev.c. It has to be there rather than in qom/, because it calls qdev_get_machine() to find the current accelerator's and machine's compat_props. Turns out calling qdev_get_machine() there is problematic. If we qdev_create() from a machine's .instance_init() method, we call device_post_init() and thus qdev_get_machine() before main() can create "/machine" in QOM. qdev_get_machine() tries to get it with container_get(), which "helpfully" creates it as "container" object, and returns that. object_apply_compat_props() tries to paper over the problem by doing nothing when the value of qdev_get_machine() isn't a TYPE_MACHINE. But the damage is done already: when main() later attempts to create the real "/machine", it fails with "attempt to add duplicate property 'machine' to object (type 'container')", and aborts. Since no machine .instance_init() calls qdev_create() so far, the bug is latent. But since I want to do that, I get to fix the bug first. Observe that object_apply_compat_props() doesn't actually need the MachineState, only its the compat_props member of its MachineClass and AccelClass. This permits a simple fix: register MachineClass and AccelClass compat_props with the object_apply_compat_props() machinery right after these classes get selected. This is actually similar to how things worked before commits ea9ce8934c5 and b66bbee39f6, except we now register much earlier. The old code registered them only after the machine's .instance_init() ran, which would've broken compatibility properties for any devices created there. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190308131445.17502-2-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-11accel: Allow to build QEMU without TCG or KVM supportAnthony PERARD1-1/+3
Instead of deny build of QEMU without a default accelerator, simply report an error when the user haven't passed -accel or -machine accel= and TCG and KVM isn't builtin. ./configure already check that at least one accelerator is available. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-01-11accel: Improve selection of the default acceleratorThomas Huth1-3/+15
When compiling with "--disable-tcg", we currently still use "tcg" as default accelerator. "kvm" should be used in this case instead. Also, some downstream distros provide QEMU binaries which have "kvm" in their names (e.g. "qemu-kvm" on RHEL or "kvm" on Ubuntu) that use KVM by default - and some users might want to do something similar with upstream binaries, too. Accomodate them by using "kvm:tcg" as default when we detect such a binary name. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1538748792-19444-1-git-send-email-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-01-07hw: apply accel compat properties without touching globalsMarc-André Lureau1-12/+0
Instead of registering compat properties as globals, let's keep them in their own array, to avoid mixing with user globals. Introduce object_apply_global_props() function, to apply compatibility properties from a GPtrArray. 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-12-11accel: register global_props like machine globalsMarc-André Lureau1-1/+8
global_props is only used for Xen xen_compat_props. It's a static array of GlobalProperty, like machine globals in SET_MACHINE_COMPAT(). Let's register the globals the same way, without extra copy allocation. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20181204142023.15982-5-marcandre.lureau@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-09accel: use g_strsplit for parsing accelerator namesDaniel P. Berrangé1-9/+7
Instead of re-using the get_opt_name() method from QemuOpts to split a string on ':', just use g_strsplit(). Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20180416111743.8473-2-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-26AccelClass: Introduce accel_setup_postIan Jackson1-0/+9
This is called just before os_setup_post. Currently none of the accelerators provide this hook, but the Xen one is going to provide one in a moment. Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2018-02-09Move include qemu/option.h from qemu-common.h to actual usersMarkus Armbruster1-1/+1
qemu-common.h includes qemu/option.h, but most places that include the former don't actually need the latter. Drop the include, and add it to the places that actually need it. While there, drop superfluous includes of both headers, and separate #include from file comment with a blank line. This cleanup makes the number of objects depending on qemu/option.h drop from 4545 (out of 4743) to 284 in my "build everything" tree. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-20-armbru@redhat.com> [Semantic conflict with commit bdd6a90a9e in block/nvme.c resolved]
2017-08-01accel: cleanup error outputLaurent Vivier1-10/+10
Only emit "XXX accelerator not found", if there are not further accelerators listed. eg accel=kvm:tcg doesn't print a "KVM accelerator not found" warning when it falls back to tcg, but a accel=kvm prints a warning, since no fallback is given. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20170717144527.24534-1-lvivier@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-28accel: introduce AccelClass.global_propsPeter Xu1-0/+6
Introduce this new field for the accelerator classes so that each specific accelerator in the future can register its own global properties to be used further by the system. It works just like how the old machine compatible properties do, but only tailored for accelerators. Introduce register_compat_props_array() for it. Export it so that it may be used in other codes as well in the future. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-3-git-send-email-peterx@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-15accel: split the tcg accelerator from accel.c fileYang Zhong1-0/+128
there are some types of accelerators in qemu, and all accelerators have their own file except tcg. tcg accelerator is also defined in accel.c file. tcg accelerator file will be splited from accel.c and re-name to tcg-all.c. accel/ directory will be created to include kvm and tcg related files. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <1496383606-18060-2-git-send-email-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>