- 02 6月, 2017 2 次提交
-
-
由 Juan Quintela 提交于
All functions are internal except for ram_mig_init(). Create migration/misc.h for this kind of functions. Signed-off-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Juan Quintela 提交于
Start removing migration code from sysemu/sysemu.h. Signed-off-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
- 29 5月, 2017 2 次提交
-
-
由 Thomas Huth 提交于
The commands 'device_add' and 'device_del' should be used nowadays instead. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-id: 1495175803-12830-1-git-send-email-thuth@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Thomas Huth 提交于
The '-usbdevice' option is considered as deprecated nowadays and we might want to remove these options in a future version of QEMU. So mark this options as deprecated in the documenation and print out a warning if it is used to tell the user what to use instead. While we're at it, improve also some other minor USB-related spots in qemu-options.hx that were not up to date anymore. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Message-id: 1495175716-12735-1-git-send-email-thuth@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 23 5月, 2017 5 次提交
-
-
由 Eric Blake 提交于
Libvirt would like to be able to distinguish between a SHUTDOWN event triggered solely by guest request and one triggered by a SIGTERM or other action on the host. While qemu_kill_report() was already able to give different output to stderr based on whether a shutdown was triggered by a host signal (but NOT by a host UI event, such as clicking the X on the window), that information was then lost to management. The previous patches improved things to use an enum throughout all callsites, so now we have something ready to expose through QMP. Note that for now, the decision was to expose ONLY a boolean, rather than promoting ShutdownCause to a QAPI enum; this is because libvirt has not expressed an interest in anything finer-grained. We can still add additional details, in a backwards-compatible manner, if a need later arises (if the addition happens before 2.10, we can replace the bool with an enum; otherwise, the enum will have to be in addition to the bool); this patch merely adds a helper shutdown_caused_by_guest() to map the internal enum into the external boolean. Update expected iotest outputs to match the new data (complete coverage of the affected tests is obtained by -raw, -qcow2, and -nbd). Here is output from 'virsh qemu-monitor-event --loop' with the patch installed: event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true} event STOP at 1492639680.732116 for domain fedora_13: <null> event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false} Note that libvirt runs qemu with -no-shutdown: the first SHUTDOWN event was triggered by an action I took directly in the guest (shutdown -h), at which point qemu stops the vcpus and waits for libvirt to do any final cleanups; the second SHUTDOWN event is the result of libvirt sending SIGTERM now that it has completed cleanup. Libvirt is already smart enough to only feed the first qemu SHUTDOWN event to the end user (remember, virsh qemu-monitor-event is a low-level debugging interface that is explicitly unsupported by libvirt, so it sees things that normal end users do not); changing qemu to emit SHUTDOWN only once is outside the scope of this series. See also https://bugzilla.redhat.com/1384007Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20170515214114.15442-6-eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Eric Blake 提交于
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: NEric 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: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Eric Blake 提交于
With the recent addition of ShutdownCause, we want to be able to pass a cause through any shutdown request, and then faithfully replay that cause when later replaying the same sequence. The easiest way is to expand the reply event mechanism to track a series of values for EVENT_SHUTDOWN, one corresponding to each value of ShutdownCause. We are free to change the replay stream as needed, since there are already no guarantees about being able to use a replay stream by any other version of qemu than the one that generated it. The cause is not actually fed back until the next patch changes the signature for requesting a shutdown; a TODO marks that upcoming change. Yes, this uses the gcc/clang extension of a ranged case label, but this is not the first time we've used non-C99 constructs. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Message-Id: <20170515214114.15442-4-eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Eric Blake 提交于
We want to track why a guest was shutdown; in particular, being able to tell the difference between a guest request (such as ACPI request) and host request (such as SIGINT) will prove useful to libvirt. Since all requests eventually end up changing shutdown_requested in vl.c, the logical change is to make that value track the reason, rather than its current 0/1 contents. Since command-line options control whether a reset request is turned into a shutdown request instead, the same treatment is given to reset_requested. This patch adds an internal enum ShutdownCause that describes reasons that a shutdown can be requested, and changes qemu_system_reset() to pass the reason through, although for now nothing is actually changed with regards to what gets reported. The enum could be exported via QAPI at a later date, if deemed necessary, but for now, there has not been a request to expose that much detail to end clients. For the most part, we turn 0 into SHUTDOWN_CAUSE_NONE, and 1 into SHUTDOWN_CAUSE_HOST_ERROR; the only specific case where we have enough information right now to use a different value is when we are reacting to a host signal. It will take a further patch to edit all call-sites that can trigger a reset or shutdown request to properly pass in any other reasons; this patch includes TODOs to point such places out. qemu_system_reset() trades its 'bool report' parameter for a 'ShutdownCause reason', with all non-zero values having the same effect; this lets us get rid of the weird #defines for VMRESET_* as synonyms for bools. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20170515214114.15442-3-eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Eric Blake 提交于
There is no signal 0 (kill(pid, 0) has special semantics to probe whether a process is alive), rather than actually sending a signal 0). So we can use the simpler 0, instead of -1, for our sentinel of whether a shutdown request due to a signal has happened. Suggested-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com> Message-Id: <20170515214114.15442-2-eblake@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 19 5月, 2017 4 次提交
-
-
由 Eduardo Habkost 提交于
All the functions in hw/audio/audio.h are called "soundhw_*()" and live in hw/audio/audiohw.c. Rename the header file for consistency. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NHervé Poussineau <hpoussin@reactos.org> Message-id: 20170508205735.23444-4-ehabkost@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Eduardo Habkost 提交于
To make it consistent with the remaining soundhw.c functions and avoid confusion with the audio_init() function in audio/audio.c, rename audio_init() to soundhw_init(). Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-id: 20170508205735.23444-3-ehabkost@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Eduardo Habkost 提交于
There's no reason to keep the soundhw table in arch_init.c. Move that code to a new hw/audio/soundhw.c file. While moving the code, trivial coding style issues were fixed. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20170508205735.23444-2-ehabkost@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Reported-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20170517122744.3541-1-kraxel@redhat.com
-
- 17 5月, 2017 1 次提交
-
-
由 Juan Quintela 提交于
This way we use the "normal" way of printing errors for hmp commands. Signed-off-by: NJuan Quintela <quintela@redhat.com> Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
-
- 12 5月, 2017 4 次提交
-
-
由 Gerd Hoffmann 提交于
Add egl-headless user interface. It doesn't provide a real user interface, it only provides opengl support using drm render nodes. It will copy back the bits rendered by the guest using virgl back to a DisplaySurface and kick the usual display update code paths, so spice and vnc and screendump can pick it up. Use it this way: qemu -display egl-headless -vnc $display qemu -display egl-headless -spice gl=off,$args Note that you should prefer native spice opengl support (-spice gl=on) if possible because that delivers better performance. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20170505104101.30589-7-kraxel@redhat.com
-
由 Igor Mammedov 提交于
add machine_run_board_init() wrapper that calls machine init for now but in follow up patches it will be used to run generic machine code that should run before machine init. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-15-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
CPUState::numa_node is still in use but now it's set by board when it creates CPU objects. So there isn't any need to set it again after all CPU's are created, since it's been already set. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-14-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Originally CPU threads were by default assigned in round-robin fashion. However it was causing issues in guest since CPU threads from the same socket/core could be placed on different NUMA nodes. Commit fb43b73b (pc: fix default VCPU to NUMA node mapping) fixed it by grouping threads within a socket on the same node introducing cpu_index_to_socket_id() callback and commit 20bb648d (spapr: Fix default NUMA node allocation for threads) reused callback to fix similar issues for SPAPR machine even though socket doesn't make much sense there. As result QEMU ended up having 3 default distribution rules used by 3 targets /virt-arm, spapr, pc/. In effort of moving NUMA mapping for CPUs into possible_cpus, generalize default mapping in numa.c by making boards decide on default mapping and let them explicitly tell generic numa code to which node a CPU thread belongs to by replacing cpu_index_to_socket_id() with @cpu_index_to_instance_props() which provides default node_id assigned by board to specified cpu_index. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-2-git-send-email-imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 10 5月, 2017 1 次提交
-
-
由 Chris Webb 提交于
When using a virtfs root filesystem, the mount_tag needs to be set to /dev/root. This can be done long-hand as -fsdev local,id=root,path=/path/to/rootfs,... -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root but the -virtfs shortcut cannot be used as it hard-codes the device identifier to match the mount_tag, and device identifiers may not contain '/': $ qemu-system-x86_64 -virtfs local,path=/foo,mount_tag=/dev/root,security_model=passthrough qemu-system-x86_64: -virtfs local,path=/foo,mount_tag=/dev/root,security_model=passthrough: duplicate fsdev id: /dev/root To support this case using -virtfs, we allow the device identifier to be specified explicitly when the mount_tag is not suitable: -virtfs local,id=root,path=/path/to/rootfs,mount_tag=/dev/root,... Signed-off-by: NChris Webb <chris@arachsys.com> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
- 05 5月, 2017 2 次提交
-
-
由 Thomas Huth 提交于
Since 'hax' is a possible accelerator nowadays, too, the '-accel' option should support it and we should mention this accelerator in the documentation, too. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <1493875481-16388-1-git-send-email-thuth@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Thomas Huth 提交于
If the user needs to specify the disk geometry, the corresponding parameters of the "-device ide-hd" option should be used instead. "-hdachs" is considered as deprecated and might be removed soon. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <1493270454-1448-1-git-send-email-thuth@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 04 5月, 2017 1 次提交
-
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
- 27 4月, 2017 1 次提交
-
-
由 Thomas Huth 提交于
If the user needs to specify the disk geometry, the corresponding parameters of the "-device ide-hd" option should be used instead. "-hdachs" is considered as deprecated and might be removed soon. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 22 4月, 2017 1 次提交
-
-
由 Paul Durrant 提交于
This patch adds a command-line option (-xen-domid-restrict) which will use the new libxendevicemodel API to restrict devicemodel [1] operations to the specified domid. (Such operations are not applicable to the xenpv machine type). This patch also adds a tracepoint to allow successful enabling of the restriction to be monitored. [1] I.e. operations issued by libxendevicemodel. Operation issued by other xen libraries (e.g. libxenforeignmemory) are currently still unrestricted but this will be rectified by subsequent patches. Signed-off-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 14 3月, 2017 1 次提交
-
-
由 Paolo Bonzini 提交于
This optimization is not necessary anymore, because the vCPU now drops the I/O thread lock even with TCG. Drop it to simplify the code and avoid the "I/O thread spun for 1000 iterations" warning. Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 09 3月, 2017 1 次提交
-
-
由 Alex Bennée 提交于
The sense of the test was inverted. Make it simple, if icount is enabled then we disabled MTTCG by default. If the user tries to force MTTCG upon us then we tell them "no". Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <rth@twiddle.net>
-
- 07 3月, 2017 1 次提交
-
-
由 Markus Armbruster 提交于
The new command line option -blockdev works like QMP command blockdev-add. The option argument may be given in JSON syntax, exactly as in QMP. Example usage: -blockdev '{"node-name": "foo", "driver": "raw", "file": {"driver": "file", "filename": "foo.img"} }' The JSON argument doesn't exactly blend into the existing option syntax, so the traditional KEY=VALUE,... syntax is also supported, using dotted keys to do the nesting: -blockdev node-name=foo,driver=raw,file.driver=file,file.filename=foo.img This does not yet support lists, but that will be addressed shortly. Note that calling qmp_blockdev_add() (say via qmp_marshal_block_add()) right away would crash. We need to stash the configuration for later instead. This is crudely done, and bypasses QemuOpts, even though storing configuration is what QemuOpts is for. Need to revamp option infrastructure to support QAPI types like BlockdevOptions. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <1488317230-26248-22-git-send-email-armbru@redhat.com>
-
- 05 3月, 2017 1 次提交
-
-
由 Markus Armbruster 提交于
The way we get QMP commands registered is high tech: * qapi-commands.py generates qmp_init_marshal() that does the actual work * it also generates the magic to register it as a MODULE_INIT_QAPI function, so it runs when someone calls module_call_init(MODULE_INIT_QAPI) * main() calls module_call_init() QEMU needs to register a few non-qapified commands. Same high tech works: monitor.c has its own qmp_init_marshal() along with the magic to make it run in module_call_init(MODULE_INIT_QAPI). QEMU also needs to unregister commands that are not wanted in this build's configuration (commit 5032a16d). Simple enough: qmp_unregister_commands_hack(). The difficulty is to make it run after the generated qmp_init_marshal(). We can't simply run it in monitor.c's qmp_init_marshal(), because the order in which the registered functions run is indeterminate. So qmp_init_marshal() registers qmp_unregister_commands_hack() separately. Since registering *appends* to the list of registered functions, this will make it run after all the functions that have been registered already. I suspect it takes a long and expensive computer science education to not find this silly. Dumb it down as follows: * Drop MODULE_INIT_QAPI entirely * Give the generated qmp_init_marshal() external linkage. * Call it instead of module_call_init(MODULE_INIT_QAPI) * Except in QEMU proper, call new monitor_init_qmp_commands() that in turn calls the generated qmp_init_marshal(), registers the additional commands and unregisters the unwanted ones. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <1488544368-30622-5-git-send-email-armbru@redhat.com>
-
- 03 3月, 2017 2 次提交
-
-
由 Hervé Poussineau 提交于
In commit af6bf132 (May 2011), ide-hd, ide-cd and scsi-cd have been added to disable default cdrom, "or else you can't put one on secondary master without -nodefaults". Make it the same for scsi-hd, so you can put one on scsi-id 2 without using -nodefaults. scsi-hd has probably been forgotten, as it has been added in the preceding commit (b443ae67). Affected users are the ones using a machine with SCSI devices and start QEMU with -device scsi-hd but without -device scsi-cd or -cdrom In that case, the default cdrom device will disappear instead of being empty. Signed-off-by: NHervé Poussineau <hpoussin@reactos.org> Message-Id: <1487623279-29930-1-git-send-email-hpoussin@reactos.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Anton Nefedov 提交于
Signed-off-by: NAnton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: NDenis 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: NPaolo Bonzini <pbonzini@redhat.com>
-
- 24 2月, 2017 1 次提交
-
-
由 KONRAD Frederic 提交于
We know there will be cases where MTTCG won't work until additional work is done in the front/back ends to support. It will however be useful to be able to turn it on. As a result MTTCG will default to off unless the combination is supported. However the user can turn it on for the sake of testing. Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com> [AJB: move to -accel tcg,thread=multi|single, defaults] Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <rth@twiddle.net>
-
- 22 2月, 2017 1 次提交
-
-
由 Igor Mammedov 提交于
Generic helper machine_query_hotpluggable_cpus() replaced target specific query_hotpluggable_cpus() callbacks so there is no need in it anymore. However inon NULL callback value is used to detect/report hotpluggable cpus support, therefore it can be removed completely. Replace it with MachineClass.has_hotpluggable_cpus boolean which is sufficient for the task. Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 21 2月, 2017 2 次提交
-
-
由 Markus Armbruster 提交于
Block backends defined with "-drive if=T" with T other than "none" are meant to be picked up by machine initialization code: a suitable frontend gets created and wired up automatically. Drives defined with if=scsi are also picked up by SCSI HBAs added with -device, unlike other interface types. Deprecate this usage, as follows. Create the frontends for onboard HBAs in machine initialization code, exactly like we do for if=ide and other interface types. Change scsi_legacy_handle_cmdline() to create a frontend only when it's still missing, and warn that this usage is deprecated. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <1487161136-9018-3-git-send-email-armbru@redhat.com>
-
由 Markus Armbruster 提交于
The logic to create frontends for -drive if=scsi is in SCSI HBAs. For all other interface types, it's in machine initialization code. A few machine types create the SCSI HBAs necessary for that. That's also not done for other interface types. I'm going to deprecate these SCSI eccentricities. In preparation for that, create the frontends in main() instead of the SCSI HBAs, by calling new function scsi_legacy_handle_cmdline() there. Note that not all SCSI HBAs create frontends. Take care not to change that. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <1487161136-9018-2-git-send-email-armbru@redhat.com> Acked-By: NPaolo Bonzini <pbonzini@redhat.com>
-
- 16 2月, 2017 4 次提交
-
-
由 Anton Nefedov 提交于
There is a suitable log mask for the purpose. Signed-off-by: NAnton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: NDenis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-4-git-send-email-den@openvz.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Anton Nefedov 提交于
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: NAnton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: NDenis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-3-git-send-email-den@openvz.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Dou Liyang 提交于
At the Qemu initialization, we call the cpu_synchronize_all_post_init() to synchronize All CPU states to KVM in the ./vl.c::main(). Currently, it is called before we initialize the CPUs, which is created by "-device" command and parsed by generic devices initialization, So, these CPUs may be ignored to synchronize. The patch moves the cpu_synchronize_all_post_init func after generic devices initialization to make sure that all the CPUs can be included. Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com> Message-Id: <1485916178-17838-1-git-send-email-douly.fnst@cn.fujitsu.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Claudio Imbrenda 提交于
This patch: * moves vm_start to cpus.c. * exports qemu_vmstop_requested, since it's needed by vm_start. * extracts vm_prepare_start from vm_start; it does what vm_start did, except restarting the cpus. * vm_start now calls vm_prepare_start and then restarts the cpus. Signed-off-by: NClaudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1487092068-16562-2-git-send-email-imbrenda@linux.vnet.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 01 2月, 2017 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Message-id: 20170125161417.31949-7-berrange@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 28 1月, 2017 1 次提交
-
-
由 Marc-André Lureau 提交于
Turn Chardev into Object. qemu_chr_alloc() is replaced by the qemu_chardev_new() constructor. It will call qemu_char_open() to open/intialize the chardev with the ChardevCommon *backend settings. The CharDriver::create() callback is turned into a ChardevClass::open() which is called from the newly introduced qemu_chardev_open(). "chardev-gdb" and "chardev-hci" are internal chardev and aren't creatable directly with -chardev. Use a new internal flag to disable them. We may want to use TYPE_USER_CREATABLE interface instead, or perhaps allow -chardev usage. Although in general we keep typename and macros private, unless the type is being used by some other file, in this patch, all types and common helper macros for qemu-char.c are in char.h. This is to help transition now (some types must be declared early, while some aren't shared) and when splitting in several units. This is to be improved later. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-