The current allocator returns IRQ numbers from a pool and does not
support IRQs reuse in any form as it did not keep track of what it
previously returned, it only keeps the last returned IRQ. Some use
cases such as PCI hot(un)plug may require IRQ release and reallocation.
This moves an allocator from SPAPR to XICS.
This switches IRQ users to use new API.
This uses LSI/MSI flags to know if interrupt is allocated.
The interrupt release function will be posted as a separate patch.
The existing interrupt allocation scheme in SPAPR assumes that
interrupts are allocated at the start time, continously and the config
will not change. However, there are cases when this is not going to work
such as:
1. migration - we will have to have an ability to choose interrupt
numbers for devices in the command line and this will create gaps in
interrupt space.
2. PCI hotplug - interrupts from unplugged device need to be returned
back to interrupt pool, otherwise we will quickly run out of interrupts.
This replaces a separate lslsi[] array with a byte in the ICSIRQState
struct and defines "LSI" and "MSI" flags. Neither of these flags set
signals that the descriptor is not allocated and not in use.
Sam bobroff [Wed, 25 Jun 2014 03:54:32 +0000 (13:54 +1000)]
spapr: Add RTAS sysparm SPLPAR Characteristics
Add support for the SPLPAR Characteristics parameter to the emulated
RTAS call ibm,get-system-parameter.
The support provides just enough information to allow "cat
/proc/powerpc/lparcfg" to succeed without generating a kernel error
message.
Without this patch the above command will produce the following kernel
message: arch/powerpc/platforms/pseries/lparcfg.c \
parse_system_parameter_string Error calling get-system-parameter \
(0xfffffffd)
Sam bobroff [Wed, 25 Jun 2014 03:54:30 +0000 (13:54 +1000)]
spapr: Fix RTAS sysparm DIAGNOSTICS_RUN_MODE
This allows the ibm,get-system-parameter RTAS call to succeed for the
DIAGNOSTICS_RUN_MODE system parameter.
The problem can be seen with "ppc64_cpu --run-mode" from the
powerpc-utils package which fails before this patch with "Machine does
not support diagnostic run mode".
This is corrected by using the rtas_st_buffer() function to write to
the buffer.
The RTAS constants are also moved out into a header file, some new
constants added and the surrounding code slightly simplified.
At the moment QEMU knows about one version of POWER8 CPU with
PVR 0x4B.0000. This CPU class is defined as "POWER8". The linux
kernel names it as "POWER8E" which is different from the name QEMU uses.
Now we get another version of POWER8 which is architecturally equivalent
to POWER8E but has different PVR 0x4D.0000 so QEMU fails to find
a PPC CPU class on these machines. The linux kernel names these CPUs as
"POWER8".
This renames the existing "POWER8" to "POWER8E" to be more precise and
stay in sync with the linux kernel.
This adds a new "POWER8" family which calls POWER8E class init function
and defines own PVR mask (used to match a CPU class) and desc (used to
create dynamic version-less CPU class).
This does not change CPU class fw_name attribute as the host POWER8
firmware keeps using "PowerPC,POWER8" on both POWER8 and POWER8E.
BALATON Zoltan [Mon, 23 Jun 2014 22:03:48 +0000 (00:03 +0200)]
mac99: Add motherboard devices before PCI cards
Change the order of creating devices for New World Mac emulation so
that devices on the motherboard are added first and PCI cards (VGA and
NIC) come later. As a side effect, this also causes OpenBIOS to map
the motherboard devices into the MMIO space to the same addresses as
on real hardware and allow clients that hardcode these addresses (e.g.
MorphOS) to find and use them until OpenBIOS is tought to map devices
to specific addresses. (On real hardware the graphics and network
cards are really on separate buses but we don't model that yet.) This
brings the memory map closer to what is found on PowerMac3,1.
Peter Maydell [Mon, 23 Jun 2014 23:05:09 +0000 (00:05 +0100)]
target-ppc: Remove unused IMM and d extract helpers
Remove the definition of the IMM and d extract helpers; these seem to have
been added as part of the initial PPC support in 2003 but never actually
used.
This turns the sPAPR support on and enables VFIO container use
in the kernel.
This extends vfio_connect_container to support VFIO_SPAPR_TCE_IOMMU type
in the host kernel.
This registers a memory listener which sPAPR IOMMU will notify when
executing H_PUT_TCE/etc DMA calls. The listener then will notify the host
kernel about DMA map/unmap operation via VFIO_IOMMU_MAP_DMA/
VFIO_IOMMU_UNMAP_DMA ioctls.
This executes VFIO_IOMMU_ENABLE ioctl to make sure that the IOMMU is free
of mappings and can be exclusively given to the user. At the moment SPAPR
is the only platform requiring this call to be implemented.
Note that the host kernel function implementing VFIO_IOMMU_DISABLE
is called automatically when container's fd is closed so there is
no need to call it explicitly from QEMU. We may need to call
VFIO_IOMMU_DISABLE explicitly in the future for some sort of dynamic
reconfiguration (PCI hotplug or dynamic IOMMU group management).
spapr_pci_vfio: Add spapr-pci-vfio-host-bridge to support vfio
The patch adds a spapr-pci-vfio-host-bridge device type
which is a PCI Host Bridge with VFIO support. The new device
inherits from the spapr-pci-host-bridge device and adds an "iommu"
property which is an IOMMU id. This ID represents a minimal entity
for which IOMMU isolation can be guaranteed. In SPAPR architecture IOMMU
group is called a Partitionable Endpoint (PE).
Current implementation supports one IOMMU id per QEMU VFIO PHB. Since
SPAPR allows multiple PHB for no extra cost, this does not seem to
be a problem. This limitation may change in the future though.
Example of use:
Configure and Add 3 functions of a multifunctional device to QEMU:
(the NEC PCI USB card is used as an example here):
-device spapr-pci-vfio-host-bridge,id=USB,iommu=4,index=7 \
-device vfio-pci,host=4:0:1.0,addr=1.0,bus=USB,multifunction=true
-device vfio-pci,host=4:0:1.1,addr=1.1,bus=USB
-device vfio-pci,host=4:0:1.2,addr=1.2,bus=USB
where:
* index=7 is a QEMU PHB index (used as source for MMIO/MSI/IO windows
offset);
* iommu=4 is an IOMMU id which can be found in sysfs:
[aik@vpl2 ~]$ cd /sys/bus/pci/devices/0004:00:00.0/
[aik@vpl2 0004:00:00.0]$ ls -l iommu_group
lrwxrwxrwx 1 root root 0 Jun 5 12:49 iommu_group -> ../../../kernel/iommu_groups/4
While most operations with VFIO IOMMU driver are generic and used inside
vfio.c, there are still some operations which only specific VFIO IOMMU
drivers implement. The first example of it will be reading a DMA window
start from the host.
This adds a helper which passes an ioctl request to the container's fd.
The helper will check if @req is known. For this, stub is added. This return
-1 on any requests for now.
POWER KVM supports an KVM_CAP_SPAPR_TCE capability which allows allocating
TCE tables in the host kernel memory and handle H_PUT_TCE requests
targeted to specific LIOBN (logical bus number) right in the host without
switching to QEMU. At the moment this is used for emulated devices only
and the handler only puts TCE to the table. If the in-kernel H_PUT_TCE
handler finds a LIOBN and corresponding table, it will put a TCE to
the table and complete hypercall execution. The user space will not be
notified.
Upcoming VFIO support is going to use the same sPAPRTCETable device class
so KVM_CAP_SPAPR_TCE is going to be used as well. That means that TCE
tables for VFIO are going to be allocated in the host as well.
However VFIO operates with real IOMMU tables and simple copying of
a TCE to the real hardware TCE table will not work as guest physical
to host physical address translation is requited.
So until the host kernel gets VFIO support for H_PUT_TCE, we better not
to register VFIO's TCE in the host.
This adds a place holder for KVM_CAP_SPAPR_TCE_VFIO capability. It is not
in upstream yet and being discussed so now it is always false which means
that in-kernel VFIO acceleration is not supported.
This adds a bool @vfio_accel flag to the sPAPRTCETable device telling
that sPAPRTCETable should not try allocating TCE table in the host kernel
for VFIO. The flag is false now as at the moment there is no VFIO.
This adds an vfio_accel parameter to spapr_tce_new_table(), the semantic
is the same. Since there is only emulated PCI and VIO now, the flag is set
to false. Upcoming VFIO support will set it to true.
This is a preparation patch so no change in behaviour is expected
At the moment spapr_rtas_register() allocates a new token number for every
new RTAS callback so numbers are not fixed and depend on the number of
supported RTAS handlers and the exact order of spapr_rtas_register() calls.
These tokens are copied into the device tree and remain the same during
the guest lifetime.
When we start another guest to receive a migration, it calls
spapr_rtas_register() as well. If the number of RTAS handlers or their
order is different in QEMU on source and destination sides, the "/rtas"
node in the device tree will differ. Since migration overwrites the device
tree (as it overwrites the entire RAM), the actual RTAS config on
the destination side gets broken.
This defines global contant values for every RTAS token which QEMU
is using today.
This changes spapr_rtas_register() to accept a token number instead of
allocating one. This changes all users of spapr_rtas_register().
This changes XICS-KVM not to cache tokens registered with KVM as they
constant now.
This makes TOKEN_BASE global as RTAS_XXX use TOKEN_BASE as
a base. TOKEN_MAX is moved and renamed too and its value is changed
to the last token + 1. Boundary checks for token values are adjusted.
This reserves token numbers for "os-term" handlers and PCI hotplug
which we are working on.
Alexander Graf [Mon, 23 Jun 2014 13:23:08 +0000 (15:23 +0200)]
PPC: Add support for Apple gdb in gdbstub
The Apple gdbstub protocol is different from the normal gdbstub protocol
used on PowerPC. Add support for the different variant, so that we can use
Apple's gdb to debug guest code.
Keep in mind that the switch is a compile time option. We can't detect
during runtime whether a gdb connecting to us is an upstream gdb or an
Apple gdb.
Sorav Bansal [Tue, 17 Jun 2014 05:54:02 +0000 (11:24 +0530)]
target-ppc: fixed translation of mcrxr instruction
Fixed bug in gen_mcrxr() in target-ppc/translate.c:
The XER[SO], XER[OV], and XER[CA] flags are stored in the least
significant bit (bit 0) of their respective registers. They need
to be shifted left (by their respective offsets) to generate the final
XER value. The old translation code for the 'mcrxr' instruction
was assuming that the flags are stored in bit 2, and was shifting them
right (incorrectly)
Tom Musta [Mon, 16 Jun 2014 16:03:19 +0000 (11:03 -0500)]
linux-user: Correct AUXV Cache Line Sizes for PowerPC
Set the AT_ICACHEBSIZE and AT_DCACHEBSIZE entries of the AUXV to match the
CPU model's cache line sizes. This fixes memory clobbering problems on more
recent Book 3s implementations; memset(p, 0, N) will use the dcbz instruction
when N is sufficiently large and many of the newer server CPUs have cache lines
sizes of 128 bytes.
Peter Maydell [Mon, 23 Jun 2014 14:55:03 +0000 (15:55 +0100)]
coroutine-win32.c: Add noinline attribute to work around gcc bug
A gcc codegen bug in x86_64-w64-mingw32-gcc (GCC) 4.6.3 means that
non-debug builds of QEMU for Windows tend to assert when using
coroutines. Work around this by marking qemu_coroutine_switch
as noinline.
If we allow gcc to inline qemu_coroutine_switch into
coroutine_trampoline, then it hoists the code to get the
address of the TLS variable "current" out of the while() loop.
This is an invalid transformation because the SwitchToFiber()
call may be called when running thread A but return in thread B,
and so we might be in a different thread context each time
round the loop. This can happen quite often. Typically.
a coroutine is started when a VCPU thread does bdrv_aio_readv:
VCPU thread
main VCPU thread coroutine I/O coroutine
bdrv_aio_readv ----->
start I/O operation
thread_pool_submit_co
<------------ yields
back to emulation
Then I/O finishes and the thread-pool.c event notifier triggers in
the I/O thread. event_notifier_ready calls thread_pool_co_cb, and
the I/O coroutine now restarts *in another thread*:
iothread
main iothread coroutine I/O coroutine (formerly in VCPU thread)
event_notifier_ready
thread_pool_co_cb -----> current = I/O coroutine;
call AIO callback
But on Win32, because of the bug, the "current" being set here the
current coroutine of the VCPU thread, not the iothread.
noinline is a good-enough workaround, and quite unlikely to break in
the future.
(Thanks to Paolo Bonzini for assistance in diagnosing the problem
and providing the detailed example/ascii art quoted above.)
Peter Maydell [Thu, 26 Jun 2014 12:33:11 +0000 (13:33 +0100)]
Merge remote-tracking branch 'remotes/afaerber/tags/qom-cpu-for-2.1' into staging
X86CPU
* Filter out MONITOR for KVM
* Fix filtering for TCG
* -cpu foo,check and -cpu foo,enforce support for TCG
* -cpu host migration support (-cpu host,migratable=no to disable)
* Add invtsc feature support
* New model: Broadwell
# gpg: Signature made Wed 25 Jun 2014 22:55:04 BST using RSA key ID 3E7E013F
# gpg: Good signature from "Andreas Färber <[email protected]>"
# gpg: aka "Andreas Färber <[email protected]>"
* remotes/afaerber/tags/qom-cpu-for-2.1:
target-i386: Broadwell CPU model
target-i386: Fix indentation of CPU model definitions
target-i386: Support "invariant tsc" flag
target-i386: block migration and savevm if invariant tsc is exposed
savevm: check vmsd for migratability status
target-i386: Set migratable=yes by default on "host" CPU mooel
target-i386: Add "migratable" property to "host" CPU model
target-i386: Support check/enforce flags in TCG mode, too
target-i386: Loop-based feature word filtering in TCG mode
target-i386: Loop-based copying and setting/unsetting of feature words
target-i386: Define TCG_*_FEATURES earlier in cpu.c
target-i386: Filter KVM and 0xC0000001 features on TCG
target-i386: Filter FEAT_7_0_EBX TCG features too
target-i386: Make TCG feature filtering more readable
target-i386: Isolate KVM-specific code on CPU feature filtering logic
target-i386: Pass FeatureWord argument to report_unavailable_features()
target-i386: Merge feature filtering/checking functions
target-i386: Simplify reporting of unavailable features
target-i386: kvm: Don't enable MONITOR by default on any CPU model
Expose "Invariant TSC" flag, if KVM is enabled. From Intel documentation:
17.13.1 Invariant TSC The time stamp counter in newer processors may
support an enhancement, referred to as invariant TSC. Processor’s
support for invariant TSC is indicated by CPUID.80000007H:EDX[8].
The invariant TSC will run at a constant rate in all ACPI P-, C-.
and T-states. This is the architectural behavior moving forward. On
processors with invariant TSC support, the OS may use the TSC for wall
clock timer services (instead of ACPI or HPET timers). TSC reads are
much more efficient and do not incur the overhead associated with a ring
transition or access to a platform resource.
Signed-off-by: Marcelo Tosatti <[email protected]>
[ehabkost: redo feature filtering to use .tcg_features]
[ehabkost: add CPUID_APM_INVTSC macro, add it to .unmigratable_flags] Signed-off-by: Eduardo Habkost <[email protected]> Signed-off-by: Andreas Färber <[email protected]>
Eduardo Habkost [Tue, 17 Jun 2014 20:31:53 +0000 (17:31 -0300)]
target-i386: Set migratable=yes by default on "host" CPU mooel
Having only migratable flags reported by default on the "host" CPU model
is safer for the following reasons:
* Existing users may expect "-cpu host" to be migration-safe, if they
take care of always using compatible host CPUs, host kernels, and
QEMU versions.
* Users who don't care aboug migration and want to enable all features
supported by the host kernel can simply change their setup to use
migratable=no.
Without this change, people using "-cpu host" will stop being able to
migrate, because now "invtsc" is getting enabled by default.
We are not setting migratable=yes by default on all X86CPU subclasses,
because users should be able to get non-migratable features enabled if
they ask for them explicitly.
target-i386: Add "migratable" property to "host" CPU model
This flag will allow the user to choose between two modes:
* All flags that can be enabled on the host, even if unmigratable
(migratable=no);
* All flags that can be enabled on the host, are known to QEMU
and migratable (migratable=yes).
The default is still migratable=false, to keep current behavior, but
this will be changed to migratable=true by another patch.
My plan was to support the "migratable" flag on all CPU classes, but
have the default to "false" on all CPU models except "host". However,
DeviceClass has no mechanism to allow a child class to have a different
property default from the parent class yet, so by now only the "host"
CPU model will support the "migratable" flag.
target-i386: Loop-based feature word filtering in TCG mode
Instead of manually filtering each feature word, add a tcg_features
field to FeatureWordInfo, and use that field to filter all feature words
in TCG mode.
The TCG_7_0_EBX_FEATURES macro was defined but never used (it even had a
typo that was never noticed). Make the existing TCG feature filtering
code use it.
Merge filter_features_for_kvm() and kvm_check_features_against_host().
Both functions made exactly the same calculations, the only difference
was that filter_features_for_kvm() changed the bits on cpu->features[],
and kvm_check_features_against_host() did error reporting.
target-i386: Simplify reporting of unavailable features
Instead of checking and calling unavailable_host_feature() once for each
bit, simply call the function (now renamed to
report_unavailable_features()) once for each feature word.
target-i386: kvm: Don't enable MONITOR by default on any CPU model
KVM never supported the MONITOR flag so it doesn't make sense to have it
enabled by default when KVM is enabled.
The rationale here is similar to the cases where it makes sense to have
a feature enabled by default on all CPU models when on KVM mode (e.g.
x2apic). In this case we are having a feature disabled by default for
the same reasons.
In this case we don't need machine-type compat code because it is
currently impossible to run a KVM VM with the MONITOR flag set.
Peter Maydell [Tue, 24 Jun 2014 16:14:57 +0000 (17:14 +0100)]
Merge remote-tracking branch 'remotes/mjt/tags/trivial-patches-2014-06-24' into staging
trivial patches for 2014-06-24
# gpg: Signature made Tue 24 Jun 2014 17:07:31 BST using RSA key ID A4C3D7DB
# gpg: Good signature from "Michael Tokarev <[email protected]>"
# gpg: aka "Michael Tokarev <[email protected]>"
# gpg: aka "Michael Tokarev <[email protected]>"
# 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: 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5
# Subkey fingerprint: 6F67 E18E 7C91 C5B1 5514 66A7 BEE5 9D74 A4C3 D7DB
* remotes/mjt/tags/trivial-patches-2014-06-24:
Add support for the arm breakpoint syscall
Increase maximum number of session of the internal TFTP server.
target-s390x: Remove unused ld_code6() function
hw/moxie/moxiesim.c: Remove unused moxie_intc_create()
target-unicore: Remove unused functions
build-sys: introduce install-prog macro to install&strip binaries and use it
tcg: mark tcg_out* and tcg_patch* with attribute 'unused'
rng-random: NULL check not needed before g_free()
block.c: Remove useless 'buf' variable
vscclient: Add required headers to fix build on FreeBSD
target-ppc: Fix compiler warning
configure: Enable TPM by default, add --disable-tpm
Fix new typos (found by codespell)
virtio-serial: remove useless set_config function
Hunter Laux [Fri, 20 Jun 2014 11:13:14 +0000 (04:13 -0700)]
Add support for the arm breakpoint syscall
OABI arm used a software interrupt(0xef9f0001) for breakpoints.
Since 2005 gdb has used the break instruction(0xe7f001f0) for EABI.
Apparently Steel Bank Common Lisp still uses the swi instruction.
This is the kernel implementation:
http://lxr.free-electrons.com/source/arch/arm/kernel/traps.c#L598
Increase maximum number of session of the internal TFTP server.
Grub fails to boot from internal TFTP server when loading more than
3 initrd files.
Grub first opens a session to the TFTP server for every initrd file and
retrieves only the file size for all.
Then it wants to download the content using the old sessions which are
already expired.
Increasing the maximum number of session of the internal TFTP
server avoids this issue.
The error message reads as following:
error: timeout reading
`/boot/ISO.ROOT/BOOTMGR'.
Michael Tokarev [Sun, 22 Jun 2014 06:55:23 +0000 (10:55 +0400)]
build-sys: introduce install-prog macro to install&strip binaries and use it
Use common rule (macro) to install and strip binaries, and use
it in all places where we install binaries, instead of fixing
bugs like 1319493 in every place.
(This fixes https://bugs.launchpad.net/bugs/1319493)
Peter Maydell [Sat, 7 Jun 2014 17:08:44 +0000 (18:08 +0100)]
tcg: mark tcg_out* and tcg_patch* with attribute 'unused'
The tcg_out* and tcg_patch* functions are utility routines that may or
may not be used by a particular backend; mark them with the 'unused'
attribute to suppress spurious warnings if they aren't used.
Stefan Weil [Tue, 17 Jun 2014 17:18:28 +0000 (19:18 +0200)]
target-ppc: Fix compiler warning
gcc reports a warning which is usually wrong:
target-ppc/dfp_helper.c: In function ‘dfp_get_digit’:
target-ppc/dfp_helper.c:417:1: warning:
control reaches end of non-void function [-Wreturn-type]
The compiler shows the warning if assert is not marked with the noreturn
attribute or if the code is compiled with -DNDEBUG.
Using g_assert_not_reached better documents the intention and does not
have these problems.
Cole Robinson [Mon, 16 Jun 2014 19:32:47 +0000 (15:32 -0400)]
configure: Enable TPM by default, add --disable-tpm
I don't see why tpm is disabled by default: it doesn't have any
external dependencies, or change default behavior. Leaving it disabled
is just going to cause it to bit rot.
Enable it by default, and add a --disable-tpm option.
Peter Maydell [Tue, 24 Jun 2014 10:14:47 +0000 (11:14 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc,pci,vhost,net fixes, enhancements
Don's patches to limit below-4g ram for pc
Marcel's pcie hotplug rewrite
Gabriel's changes to e1000 auto-negotiation
qemu char bugfixes by Stefan
misc bugfixes
Signed-off-by: Michael S. Tsirkin <[email protected]>
# gpg: Signature made Mon 23 Jun 2014 16:25:19 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <[email protected]>"
# gpg: aka "Michael S. Tsirkin <[email protected]>"
* remotes/mst/tags/for_upstream: (23 commits)
xen-hvm: Handle machine opt max-ram-below-4g
pc & q35: Add new machine opt max-ram-below-4g
xen-hvm: Fix xen_hvm_init() to adjust pc memory layout
pcie: coding style tweak
hw/pcie: better hotplug/hotunplug support
hw/pcie: implement power controller functionality
hw/pcie: correct debug message
q35: Use PC_Q35_COMPAT_1_4 on pc-q35-1.4 compat_props
virtio-pci: Report an error when msix vectors init fails
qemu-char: avoid leaking unused fds in tcp_get_msgfds()
qemu-char: fix qemu_chr_fe_get_msgfd()
qapi/string-output-visitor: fix human output
e1000: factor out checking for auto-negotiation availability
e1000: move e1000_autoneg_timer() to after set_ics()
e1000: signal guest on successful link auto-negotiation
e1000: improve auto-negotiation reporting via mii-tool
e1000: emulate auto-negotiation during external link status change
qtest: fix vhost-user-test unbalanced mutex locks
qtest: fix qtest for vhost-user
libqemustub: add more stubs for qemu-char
...
Peter Maydell [Mon, 23 Jun 2014 17:26:58 +0000 (18:26 +0100)]
Merge remote-tracking branch 'remotes/rth/tcg-ppc-merge-1' into staging
* remotes/rth/tcg-ppc-merge-1: (25 commits)
tcg-ppc: Use the return address as a base pointer
tcg-ppc: Merge cache-utils into the backend
qemu/osdep: Remove the need for qemu_init_auxval
tcg-ppc: Rename the tcg/ppc64 backend
tcg-ppc: Remove the backend
tcg-ppc64: Merge ppc32 shifts
tcg-ppc64: Support mulsh_i32
tcg-ppc64: Merge ppc32 register usage
tcg-ppc64: Merge ppc32 qemu_ld/st
tcg-ppc64: Merge ppc32 brcond2, setcond2, muluh
tcg-ppc64: Begin merging ppc32 with ppc64
tcg-ppc64: Fix sub2 implementation
tcg-ppc64: Merge 32-bit ABIs into the prologue / frame code
tcg-ppc64: Adjust tcg_out_call for ELFv2
tcg-ppc64: Support the ppc64 elfv2 ABI
tcg-ppc64: Use the correct test in tcg_out_call
tcg-ppc64: Better parameterize the stack frame
tcg-ppc64: Fix TCG_TARGET_CALL_STACK_OFFSET
tcg-ppc64: Move call macros out of tcg-target.h
tcg-ppc64: Make TCG_AREG0 and TCG_REG_CALL_STACK enum constants
...
Juan Quintela [Sat, 5 Apr 2014 18:16:22 +0000 (20:16 +0200)]
vmstate: Return error in case of error
If there is an error while loading a field, we should stop reading and
not continue with the rest of fields. And we should also set an error
in qemu_file.
Amit Shah [Fri, 20 Jun 2014 13:26:10 +0000 (18:56 +0530)]
tests: vmstate static checker: add dump1 and dump2 files
These are stripped-down JSON data as obtained from the -dump-vmstate
option. The two files are identical in this commit, and will be
modified in the later commits to show what the script does with the
data.
Amit Shah [Fri, 20 Jun 2014 13:26:08 +0000 (18:56 +0530)]
migration: dump vmstate info as a json file for static analysis
This commit adds a new command, '-dump-vmstate', that takes a filename
as an argument. When executed, QEMU will dump the vmstate information
for the machine type it's invoked with to the file, and quit.
The JSON-format output can then be used to compare the vmstate info for
different QEMU versions, specifically to test whether live migration
would break due to changes in the vmstate data.
A Python script that compares the output of such JSON dumps is included
in the following commit.
Michael R. Hines [Tue, 18 Feb 2014 02:34:06 +0000 (10:34 +0800)]
rdma: bug fixes
1. Fix small memory leak in parsing inet address from command line in data_init()
2. Fix ibv_post_send() return value check and pass error code back up correctly.
3. Fix rdma_destroy_qp() segfault after failure to connect to destination.
Peter Maydell [Mon, 23 Jun 2014 16:47:28 +0000 (17:47 +0100)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20140623-2' into staging
A couple of s390-ccw bios bugfixes: Fix booting for some bootmaps and get
the devices to a sane state before running the guest.
# gpg: Signature made Mon 23 Jun 2014 13:22:32 BST using RSA key ID C6F02FAF
# gpg: Can't check signature: public key not found
* remotes/cohuck/tags/s390x-20140623-2:
pc-bios/s390-ccw: update s390-ccw.img binary
pc-bios/s390-ccw: fix for fragmented SCSI bootmap
pc-bios/s390-ccw: do a subsystem reset before running the guest
pc-bios/s390-ccw: virtio_load_direct() can't load max number of sectors
Paolo Bonzini [Wed, 18 Jun 2014 06:44:00 +0000 (08:44 +0200)]
monitor: protect event emission
Event emission must be protected by a mutex because of access to
the shared rate-limiting state, and to guard against concurrent
monitor "hot-plug" by means of human-monitor-command.
Paolo Bonzini [Wed, 18 Jun 2014 06:43:58 +0000 (08:43 +0200)]
qemu-char: make writes thread-safe
This will let threads other than the I/O thread raise QMP events.
GIOChannel is thread-safe, and send and receive state is usually
well-separated. The only driver that requires some care is the
pty driver, where some of the state is shared by the read and write
sides. That state is protected with the chr_write_lock too.