- 30 6月, 2017 15 次提交
-
-
由 Bharata B Rao 提交于
If ppc_cpu_realizefn() fails after cpu_exec_realizefn() has been called, we will have to undo whatever cpu_exec_realizefn() did by explicitly calling cpu_exec_unrealizeffn() which is currently missing. Failure to do this proper cleanup will result in CPU which was never fully realized to linger on the cpus list causing SIGSEGV later (for eg when running "info cpus"). Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Commit 5bc8d26d ("spapr: allocate the ICPState object from under sPAPRCPUCore") moved ICPState objects from the machine to CPU cores. This is an improvement since we no longer allocate ICPState objects that will never be used. But it has the side-effect of breaking migration of older machine types from older QEMU versions. This patch allows spapr to register dummy "icp/server" entries to vmstate. These entries use a dedicated VMStateDescription that can swallow and discard state of an incoming migration stream, and that don't send anything on outgoing migration. As for real ICPState objects, the instance_id is the cpu_index of the corresponding vCPU, which happens to be equal to the generated instance_id of older machine types. The machine can unregister/register these entries when CPUs are dynamically plugged/unplugged. This is only available for pseries-2.9 and older machines, thanks to a compat property. Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
The ICPState objects are currently registered to vmstate as qdev objects. Their instance ids are hence computed automatically in the migration code, and thus depends on the order the CPU cores were plugged. If the destination had its CPU cores plugged in a different order than the source, then ICPState objects will have different instance_ids and load the wrong state. Since CPU objects have a reliable cpu_index which is already used as instance_id in vmstate, let's use it for ICPState as well. Please note that this doesn't break migration. Older machine types used to allocate and realize all ICPState objects at machine init time, for the whole lifetime of the machine. The qdev instance ids are thus 0,1,2... nr_servers and happen to map to the vCPU indexes. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
The mmu fault handler should return 0 if it was able to successfully handle the fault and a positive value otherwise. Currently the tcg radix mmu fault handler will return 1 after successfully handling a fault in virtual mode. This is incorrect so fix it so that it returns 0 in this case. The handler already correctly returns 0 when a fault was handled in real mode and 1 if an interrupt was generated. Fixes: d5fee0bb ("target/ppc: Implement ISA V3.00 radix page fault handler") Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
Since the introduction of MTTCG, using the msgsnd instruction abort()s if being called without holding the BQL. So let's protect that part of the code now with qemu_mutex_lock_iothread(). Buglink: https://bugs.launchpad.net/qemu/+bug/1694998Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
Fix migration of radix guests by ensuring that we issue KVM_PPC_CONFIGURE_V3_MMU for radix case post migration. Reported-by: NNageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bharata B Rao 提交于
Add a "no HPT" encoding (using value -1) to the HTAB migration stream (in the place of HPT size) when the guest doesn't allocate HPT. This will help the target side to match target HPT with the source HPT and thus enable successful migration. Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
Migrating between different CPU versions is a bit complicated for ppc. A long time ago, we ensured identical CPU versions at either end by checking the PVR had the same value. However, this breaks under KVM HV, because we always have to use the host's PVR - it's not virtualized. That would mean we couldn't migrate between hosts with different PVRs, even if the CPUs are close enough to compatible in practice (sometimes identical cores with different surrounding logic have different PVRs, so this happens in practice quite often). So, we removed the PVR check, but instead checked that several flags indicating supported instructions matched. This turns out to be a bad idea, because those instruction masks are not architected information, but essentially a TCG implementation detail. So changes to qemu internal CPU modelling can break migration - this happened between qemu-2.6 and qemu-2.7. That was addressed by 146c11f1 "target-ppc: Allow eventual removal of old migration mistakes". Now, verification of CPU compatibility across a migration basically doesn't happen. We simply ignore the PVR of the incoming migration, and hope the cpu on the destination is close enough to work. Now that we've cleaned up handling of processor compatibility modes for pseries machine type, we can do better. For new machine types (pseries-2.10+) We allow migration if: * The source and destination PVRs are for the same type of CPU, as determined by CPU class's pvr_match function OR * When the source was in a compatibility mode, and the destination CPU supports the same compatibility mode For older machine types we retain the existing behaviour - current CAS code will usually set a compat mode which would break backwards migration if we made them use the new behaviour. [Fixed from an earlier version by Greg Kurz]. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 David Gibson 提交于
Currently, the CPU compatibility mode is set when the cpu is initialized, then again when the guest negotiates features. This means if a guest negotiates a compatibility mode, then reboots, that compatibility mode will be retained across the reset. Usually that will get overridden when features are negotiated on the next boot, but it's still not really correct. This patch moves the initial set up of the compatibility mode from cpu init to reset time. The mode *is* retained if the reboot was caused by the feature negotiation (it might be important in that case, though it's unlikely). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 David Gibson 提交于
Server class POWER CPUs have a "compat" property, which is used to set the backwards compatibility mode for the processor. However, this only makes sense for machine types which don't give the guest access to hypervisor privilege - otherwise the compatibility level is under the guest's control. To reflect this, this removes the CPU 'compat' property and instead creates a 'max-cpu-compat' property on the pseries machine. Strictly speaking this breaks compatibility, but AFAIK the 'compat' option was never (directly) used with -device or device_add. The option was used with -cpu. So, to maintain compatibility, this patch adds a hack to the cpu option parsing to strip out any compat options supplied with -cpu and set them on the machine property instead of the now deprecated cpu property. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NGreg Kurz <groug@kaod.org> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Greg Kurz 提交于
This may be used for deprecated object properties that are kept for backwards compatibility. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Tested-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
When using the 40p machine, soundhw_init() is currently called twice, one time from vl.c and one time from ibm_40p_init(). The call in ibm_40p_init() was likely just a copy-and-paste from a old version of the prep machine - but there the call to audio_init() (which was the previous name of this function) has been removed many years ago already, with commit b3e6d591 ("audio: enable PCI audio cards for all PCI-enabled targets"), so we certainly also do not need the soundhw_init() in the 40p function anymore nowadays. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NSahid Ferdjaoui <sferdjao@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NHervé Poussineau <hpoussin@reactos.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Peter Maydell 提交于
HMP pull 2017-06-29 # gpg: Signature made Thu 29 Jun 2017 17:27:55 BST # gpg: using RSA key 0x0516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * remotes/dgilbert/tags/pull-hmp-20170629: Add chardev-send-break monitor command monitor: Add -a (all) option to info registers Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Stefan Fritsch 提交于
Sending a break on a serial console can be useful for debugging the guest. But not all chardev backends support sending breaks (only telnet and mux do). The chardev-send-break command allows to send a break even if using other backends. Signed-off-by: NStefan Fritsch <sf@sfritsch.de> Acked-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170611074817.13621-1-sf@sfritsch.de> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Use 'send a break' in all 3 pieces of text as suggested by eblake
-
由 Suraj Jitindar Singh 提交于
The info registers command in the qemu monitor is used to dump register values. Currently this command uses the monitor cpu (which can be set by the user) as the cpu for whose registers will be dumped. Sometimes it is useful to see the registers for all cpus and currently this requires setting the monitor cpu and the re-running the command for each cpu in the system. I would be nice if there was an easier way to do this. Add the "-a" option to the info registers command to dump the register values for all cpus. Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20170608054116.17203-1-sjitindarsingh@gmail.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
- 29 6月, 2017 13 次提交
-
-
由 Peter Maydell 提交于
- fixes a minor bug that could possibly prevent old guests to remove directories - makes default permissions for new files configurable from the cmdline when using mapped security modes - handle transport errors - g_malloc()+memcpy() converted to g_memdup() # gpg: Signature made Thu 29 Jun 2017 14:12:42 BST # gpg: using DSA key 0x02FC3AEB0101DBC2 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" # gpg: aka "Greg Kurz <groug@free.fr>" # gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>" # gpg: aka "Gregory Kurz (Groug) <groug@free.fr>" # gpg: aka "[jpeg image of size 3330]" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2 * remotes/gkurz/tags/for-upstream: 9pfs: handle transport errors in pdu_complete() xen-9pfs: disconnect if buffers are misconfigured virtio-9p: break device if buffers are misconfigured virtio-9p: message header is 7-byte long virtio-9p: record element after sanity checks 9pfs: replace g_malloc()+memcpy() with g_memdup() 9pfs: local: Add support for custom fmode/dmode in 9ps mapped security modes 9pfs: local: remove: use correct path component Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 John Arbuckle 提交于
The [NSEvent modifierFlags] method returns an NSEventModifierFlags type value in Mac OS 10.10. It use to be of type NSUInteger. Replacing NSEventModifierFlags with NSUInteger allows for the cooca.m file to be compiled on older versions of Mac OS. This patch was been tested on Mac OS 10.6 and Mac OS 10.12 without problem. Signed-off-by: NJohn Arbuckle <programmingkidx@gmail.com> Message-id: F6C36C1A-4661-48F4-BEA6-3994889927D0@gmail.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Greg Kurz 提交于
Contrary to what is written in the comment, a buggy guest can misconfigure the transport buffers and pdu_marshal() may return an error. If this ever happens, it is up to the transport layer to handle the situation (9P is transport agnostic). This fixes Coverity issue CID1348518. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Stefano Stabellini 提交于
Implement xen_9pfs_disconnect by unbinding the event channels. On xen_9pfs_free, call disconnect if any event channels haven't been disconnected. If the frontend misconfigured the buffers set the backend to "Closing" and disconnect it. Misconfigurations include requesting a read of more bytes than available on the ring buffer, or claiming to be writing more data than available on the ring buffer. Signed-off-by: NStefano Stabellini <stefano@aporeto.com> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
The 9p spec at http://man.cat-v.org/plan_9/5/intro reads: "Each 9P message begins with a four-byte size field specify- ing the length in bytes of the complete message including the four bytes of the size field itself. The next byte is the message type, one of the constants in the enumeration in the include file <fcall.h>. The next two bytes are an iden- tifying tag, described below." ie, each message starts with a 7-byte long header. The core 9P code already assumes this pretty much everywhere. This patch does the following: - makes the assumption explicit in the common 9p.h header, since it isn't related to the transport - open codes the header size in handle_9p_output() and hardens the sanity check on the space needed for the reply message Signed-off-by: NGreg Kurz <groug@kaod.org> Acked-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Greg Kurz 提交于
If the guest sends a malformed request, we end up with a dangling pointer in V9fsVirtioState. This doesn't seem to cause any bug, but let's remove this side effect anyway. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Marc-André Lureau 提交于
I found these pattern via grepping the source tree. I don't have a coccinelle script for it! Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Tobias Schramm 提交于
In mapped security modes, files are created with very restrictive permissions (600 for files and 700 for directories). This makes file sharing between virtual machines and users on the host rather complicated. Imagine eg. a group of users that need to access data produced by processes on a virtual machine. Giving those users access to the data will be difficult since the group access mode is always 0. This patch makes the default mode for both files and directories configurable. Existing setups that don't know about the new parameters keep using the current secure behavior. Signed-off-by: NTobias Schramm <tobleminer@gmail.com> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Bruce Rogers 提交于
Commit a0e640a8 introduced a path processing error. Pass fstatat the dirpath based path component instead of the entire path. Signed-off-by: NBruce Rogers <brogers@suse.com> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Peter Maydell 提交于
migration/next for 20170628 # gpg: Signature made Wed 28 Jun 2017 12:16:44 BST # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration/20170628: exec: fix access to ram_list.dirty_memory when sync dirty bitmap migration: add "return-path" capability vmstate: error hint for failed equal checks migration: add comment for TYPE_MIGRATE migration: hmp: dump globals migration: merge enforce_config_section somewhat migration: move skip_section_footers migration: move skip_configuration out migration: move only_migratable to MigrationState migration: move global_state.optional out migration: let MigrationState be a qdev vl: clean up global property registration accel: introduce AccelClass.global_props machine: export register_compat_prop() Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Xen 2017/06/27 # gpg: Signature made Tue 27 Jun 2017 23:02:43 BST # gpg: using RSA key 0x894F8F4870E1AE90 # gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>" # gpg: aka "Stefano Stabellini <sstabellini@kernel.org>" # Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90 * remotes/sstabellini/tags/xen-20170627-tag: xen-disk: add support for multi-page shared rings xen-disk: only advertize feature-persistent if grant copy is not available xen/disk: don't leak stack data via response ring Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
The 32-bit PPC auxv is a bit complicated because in the mists of time it used to be 16-aligned rather than directly after the environment. Older glibc versions had code to try to probe for whether it needed alignment or not: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/powerpc/dl-sysdep.c;hb=e84eabb3871c9b39e59323bf3f6b98c2ca9d1cd0 and the kernel has code which puts some magic entries at the bottom to ensure that the alignment probe fails: http://elixir.free-electrons.com/linux/latest/source/arch/powerpc/include/asm/elf.h#L158 QEMU has similar code too, but it was broken by commit 7c4ee5bc, which changed elfload.c from filling in the auxv starting at the highest address and working down to starting at the lowest address and working up. This means that the ARCH_DLINFO hook must now be invoked first rather than last, and the entries in it for PPC must be reversed so that the magic AT_IGNOREPPC entries come at the lowest address in the auxv as they should. The effect of this was that if running a guest binary that used an old glibc with the alignment probing the guest ld.so code would segfault if the size of the guest environment and argv happened to put the auxv at an address that triggered the alignment code in the guest glibc. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <rth@twiddle.net> Tested-by: NRichard Henderson <rth@twiddle.net> Message-id: 1498582198-6649-1-git-send-email-peter.maydell@linaro.org
-
- 28 6月, 2017 12 次提交
-
-
由 Haozhong Zhang 提交于
In cpu_physical_memory_sync_dirty_bitmap(rb, start, ...), the 2nd argument 'start' is relative to the start of the ramblock 'rb'. When it's used to access the dirty memory bitmap of ram_list (i.e. ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION]->blocks[]), an offset to the start of all RAM (i.e. rb->offset) should be added to it, which has however been missed since c/s 6b6712ef. For a ramblock of host memory backend whose offset is not zero, cpu_physical_memory_sync_dirty_bitmap() synchronizes the incorrect part of the dirty memory bitmap of ram_list to the per ramblock dirty bitmap. As a result, a guest with host memory backend may crash after migration. Fix it by adding the offset of ramblock when accessing the dirty memory bitmap of ram_list in cpu_physical_memory_sync_dirty_bitmap(). Reported-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com> Message-Id: <20170628083704.24997-1-haozhong.zhang@intel.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Tested-by: NJuan Quintela <quintela@redhat.com> Tested-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
When this capability is enabled, QEMU will use the return path even for precopy migration. This is helpful at least in one case when destination failed to load the image while source quited without confirmation. With return path, source will wait for the last response from destination, and if destination fails, it'll fail the migration on source, then the guest can be run again on the source (rather than assuming to be good, then the guest will be lost after source quits). It needs to be enabled explicitly on source, otherwise disabled. Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498472935-14461-1-git-send-email-peterx@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Halil Pasic 提交于
In some cases a failing VMSTATE_*_EQUAL does not mean we detected a bug, but it's actually the best we can do. Especially in these cases a verbose error message is required. Let's introduce infrastructure for specifying a error hint to be used if equal check fails. Let's do this by adding a parameter to the _EQUAL macros called _err_hint. Also change all current users to pass NULL as last parameter so nothing changes for them. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170623144823.42936-1-pasic@linux.vnet.ibm.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
It'll be strange that the migration object inherits TYPE_DEVICE. Add some explanations to it. Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498634144-26508-1-git-send-email-peterx@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
Now we have some globals that can be configured for migration. Dump them in HMP info migration for better debugging. (we can also use this to monitor whether COMPAT fields are applied correctly on compatible machines) Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-11-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
These two parameters: - MachineState::enforce_config_section - MigrationState::send_configuration are playing similar role here. This patch merges the first one into second, then we'll have a single place to reference whether we need to send the configuration section. I didn't remove the MachineState.enforce_config_section field since when applying that machine property (in machine_set_property()) we haven't yet initialized global properties and migration object. Then, it's still not easy to pass that boolean to MigrationState at such an early time. A natural benefit for current patch is that now we kept the meaning of "enforce-config-section" since it'll still have the highest priority (that's what "enforce" mean I guess). Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-10-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
Move it into MigrationState, revert its meaning and renaming it to send_section_footer, with a property bound to it. Same trick is played like previous patches. Removing savevm_skip_section_footers(). Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-9-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
It was in SaveState but now moved to MigrationState altogether, reverted its meaning, then renamed to "send_configuration". Again, using HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for xen_init(). Removing savevm_skip_configuration(). Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-8-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
One less global variable, and it does only matter with migration. We keep the old "--only-migratable" option, but also now we support: -global migration.only-migratable=true Currently still keep the old interface. Hmm, now vl.c has no way to access migrate_get_current(). Export a function for it to setup only_migratable. Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-7-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
Put it into MigrationState then we can use the properties to specify whether to enable storing global state. Removing global_state_set_optional() since now we can use HW_COMPAT_2_3 for x86/power, and AccelClass.global_props for Xen. Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-6-git-send-email-peterx@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
Let the old man "MigrationState" join the object family. Direct benefit is that we can start to use all the property features derived from current QDev, like: HW_COMPAT_* bits, command line setup for migration parameters (so will never need to set them up each time using HMP/QMP, this is really, really attractive for test writters), etc. I see no reason to disallow this happen yet. So let's start from this one, to see whether it would be anything good. Now we init the MigrationState struct statically in main() to make sure it's initialized after global properties are applied, since we'll use them during creation of the object. No functional change at all. Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-5-git-send-email-peterx@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Xu 提交于
It's not that clear on how the global properties are registered to global_props (and also its priority relationship). Let's provide a single function to be called in main() for that, with comment to explain it a bit. Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-4-git-send-email-peterx@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-