Fix various small problems in hexdump code, such as:
- Reference to non-existing field etsec->nic->nc.name is replaced
with nc->name
- Type mismatch warnings
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Document:
1. The new debug and logfile options with their usages
2. New json format and its usage and
3. update "GlusterFS, Device URL Syntax" section in "Invocation"
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
The QMP definition of BlockdevOptionsNfs:
{ 'struct': 'BlockdevOptionsNfs',
'data': { 'server': 'NFSServer',
'path': 'str',
'*user': 'int',
'*group': 'int',
'*tcp-syn-count': 'int',
'*readahead-size': 'int',
'*page-cache-size': 'int',
'*debug-level': 'int' } }
To make this consistent with other block protocols like gluster, lets
change s/debug-level/debug/
Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
The QMP definition of BlockdevOptionsGluster:
{ 'struct': 'BlockdevOptionsGluster',
'data': { 'volume': 'str',
'path': 'str',
'server': ['GlusterServer'],
'*debug-level': 'int',
'*logfile': 'str' } }
But instead of 'debug-level we have exported 'debug' as the option for choosing
debug level of gluster protocol driver.
This patch fix QMP definition BlockdevOptionsGluster
s/debug-level/debug/
Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
While testing rth's latest TCG patches with risu I found ldaxp was
broken. Investigating further I found it was broken by 1dd089d0 when
the cmpxchg atomic work was merged. As part of that change the code
attempted to be clever by doing a single 64 bit load and then shuffle
the data around to set the two 32 bit registers.
As I couldn't quite follow the endian magic I've simply partially
reverted the change to the original code gen_load_exclusive code. This
doesn't affect the cmpxchg functionality as that is all done on in
gen_store_exclusive part which is untouched.
I've also restored the comment that was removed (with a slight tweak
to mention cmpxchg).
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Richard Henderson <rth@twiddle.net>
Message-id: 20161202173454.19179-1-alex.bennee@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The documentation parser we are going to add expects a section name to
end with ':', otherwise the comment is treated as free-form text body.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161117155504.21843-9-marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The documentation parser we are going to add only handles a single
symbol per line.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161117155504.21843-8-marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
There are various mismatch:
- invalid symbols
- section and member symbols mismatch
- enum or union values vs 'type'
The documentation parser catches all these cases.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161117155504.21843-7-marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
According to docs/qapi-code-gen.txt, there needs to be '##' to start a
and end a symbol section, that's also what the documentation parser
expects.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20161117155504.21843-5-marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
guest-get-memory-block-info documentation should have only one
"Returns:".
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20161117155504.21843-3-marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The qobject_from_jsonf() function implements a pseudo-printf
language for creating a QObject; however, it is hard-coded to
only parse a subset of formats understood by -Wformat, and is
not a straight synonym to bare printf(). In particular, any
use of an int64_t integer works only if the system's
definition of PRId64 matches what the parser expects; which
works on glibc (%lld or %ld depending on 32- vs. 64-bit) and
mingw (%I64d), but not on Mac OS (%qd). Rather than enhance
the parser, it is just as easy to force the use of int (where
the value is small enough) or long long instead of int64_t,
which we know always works.
This should cover all remaining testsuite uses of
qobject_from_json[fv]() that were trying to rely on PRId64,
although my proof for that was done by adding in asserts and
checking that 'make check' still passed, where such asserts
are inappropriate during hard freeze. A later series in 2.9
may remove all dynamic JSON parsing, but that's a bigger task.
Reported by: G 3 <programmingkidx@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1479922617-4400-4-git-send-email-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Rename value64 to value_ll]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The qobject_from_jsonv() function implements a pseudo-printf
language for creating a QObject; however, it is hard-coded to
only parse a subset of formats understood by -Wformat, and is
not a straight synonym to bare printf(). In particular, any
use of an int64_t integer works only if the system's
definition of PRId64 matches what the parser expects; which
works on glibc (%lld or %ld depending on 32- vs. 64-bit) and
mingw (%I64d), but not on Mac OS (%qd). Rather than enhance
the parser, it is just as easy to use normal printf() for
this particular conversion, matching what is done elsewhere
in this file [1], which is safe in this instance because the
format does not contain any of the problematic differences
(bare '%' or the '%s' format).
The use of PRId64 for a variable named 'pid' is gross, but it
is a sad reality of the 64-bit mingw environment, which
mistakenly defines pid_t as a 64-bit type even though getpid()
returns 'int' on that platform [2]. Our definition of the
QGA GuestExec type defines 'pid' as a 64-bit entity, and we
can't tighten it to 'int32' unless the mingw header is fixed.
Using 'long long' instead of 'int64_t' just so that we can
stick with qobject_from_jsonv("%lld") instead of printf() is
not any prettier, since we may have later type churn anyways.
[1] see 'git grep -A2 strdup_printf tests/test-qga.c'
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1397787
Reported by: G 3 <programmingkidx@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1479922617-4400-3-git-send-email-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The qobject_from_jsonf() function implements a pseudo-printf
language for creating a QObject; however, it is hard-coded to
only parse a subset of formats understood by -Wformat, and is
not a straight synonym to bare printf(). In particular, any
use of an int64_t integer works only if the system's
definition of PRId64 matches what the parser expects; which
works on glibc (%lld or %ld depending on 32- vs. 64-bit) and
mingw (%I64d), but not on Mac OS (%qd). Rather than enhance
the parser, it is just as easy to use 'long long', which we
know always works. There are few enough callers of
qobject_from_json[fv]() that it is easy to audit that this is
the only non-testsuite caller that was actually relying on
this particular conversion.
Reported by: G 3 <programmingkidx@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1479922617-4400-2-git-send-email-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Cast tv.tv_sec, tv.tv_usec to long long for type correctness]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA,
'cirrus_get_bpp' returns zero(0), which could lead to a divide
by zero error in while copying pixel data. The same could occur
via blit pitch values. Add check to avoid it.
Reported-by: Huawei PSIRT <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 1476776717-24807-1-git-send-email-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Depending on QEMU network setup it is possible for us to receive a
complete Ethernet packet that is less 64 bytes long. One such example is
when QEMU is configured to use a standalone TAP device (not set to be a
part of any bridge) receives and ARP packet. In cases like that we need
to add more than just 4-bytes of CRC padding and ensure that our payload
is at least 60 bytes long, such that, when combined with CRC padding
bytes the resulting size is at least 802.3 minimum MTU bytes
long (64). Failing to do that results in code in etsec_walk_rx_ring()
setting BD_RX_SH which, in turn, makes corresponding Linux driver of
emulated host to reject buffer as a runt packet
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
ColdFire Fast Ethernet Controller uses a receive buffer size
register(EMRBR) to hold maximum size of all receive buffers.
It is set by a user before any operation. If it was set to be
zero, ColdFire emulator would go into an infinite loop while
receiving data in mcf_fec_receive. Add check to avoid it.
Reported-by: Wjjzhang <wjjzhang@tencent.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
In update_cursor_data_virgl function, if the 'width'/ 'height'
is not equal to current cursor's width/height it will return
without free the 'data' allocated previously. This will lead
a memory leak issue. This patch fix this issue.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Message-id: 58187760.41d71c0a.cca75.4cb9@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In virgl_cmd_get_capset_info dispatch function, the 'resp' hasn't
been full initialized before writing to the guest. This will leak
the 'resp.padding' and 'resp.hdr.padding' fieds to the guest. This
patch fix this issue.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Message-id: 5818661e.0860240a.77264.7a56@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently if the client keeps sending the same monitor config to
QEMU/spice-server, QEMU will always raise
a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG regardless of whether there was a
change or not.
Guest-side (with fedora 25), the kernel QXL KMS driver will also forward the
event to user-space without checking if there were actual changes.
Next in line are gnome-shell/mutter (on a default f25 install), which
will try to reconfigure everything without checking if there is anything
to do.
Where this gets ugly is that when applying the resolution changes,
gnome-shell/mutter will call drmModeRmFB, drmModeAddFB, and
drmModeSetCrtc, which will cause the primary surface to be destroyed and
recreated by the QXL KMS driver. This in turn will cause the client to
resend a client monitors config message, which will cause QEMU to reemit
an interrupt with an unchanged monitors configuration, ...
This causes https://bugzilla.redhat.com/show_bug.cgi?id=1266484
This commit makes sure that we only emit
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG when there are actual configuration
changes the guest should act on.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Message-id: 20161028144840.18326-1-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fixed issues in the MIPSDSP64 instructions dextp and dextpdp.
Shifting can go out of 32 bit range.
https://bugs.launchpad.net/qemu/+bug/1631625
Reported-by: Thomas Huth <thuth@redhat.com>
Reported-by: Jia Liu <proljc@gmail.com>
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Needed to emit FPU exception on Loongson multimedia instructions
executing if Status:CU1 is clear. or FPR changes may be missed
on Linux.
Signed-off-by: Heiher <wangr@lemote.com>
Signed-off-by: Fuxin Zhang <zhangfx@lemote.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Just a single migration / hotplug fix in this set. I believe it's
important enough to go in this late in the 2.8 release process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJYP6qFAAoJEGw4ysog2bOSNKMQANcyLWs27Iim3jW397wDombJ
X0rC0luweUXkFzT4eyf2o+7c2HgXYzokUOElrlhU5AN93M64WaJb2chw+nn8WuZH
H7Ef1WR9yIVc3mVB+B8fWo4QIxehTFjKVTgGwAv+F1WAcGeIR9TPVdquxl3giYUb
Mqx+Kh4jIWzVlmOeaYql3DIQX80zMhDQdUoKEbL93pXx6PfJKez7yypygDdf6BPb
PbrA4wFBKay83bwrIVWw+OK4i1v1zqF+A1+UyJSCCkbPui2UGzp1j0xqaI70SUwP
7JxOMhhhbQHKyC2pIdtlmxBBUuCjG4n3LskouKyVZu/ys8gybszoHdjLdavTFLO5
Slri4iwjyPieW+nUrNVdhXJRDE8/knQtPf6Xqby8uOD0g8qJ7RSV7hN5LROZ30HU
HONMvu3b4z0Rruls1l8z+gHvzNU1Raoh6XzfPUF7NtxwuTMcZ0JkeanSHiax5GdH
UgCOwKmXp0ZCuQ8Zzep3nyuZsCNxQKk5BR/nRG9LTu6skwED9BQZzEKxcKj6DpTu
ipPNrHyfM+s4MX1nURZreX1+HHLxAacxfdGZxuN6s+69acILui4igRiyscl8KJyn
vSXq6ipjfi0bbsDJJ5FxlVcflkf06n6xhC2ncNydnSoxCjIVEh3sUdEVlhPvKDaV
UwZSmf8kse3UQn+HgSCn
=Kar4
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'dgibson/tags/ppc-for-2.8-20161201' into staging
ppc patch queue 2016-12-01
Just a single migration / hotplug fix in this set. I believe it's
important enough to go in this late in the 2.8 release process.
# gpg: Signature made Thu 01 Dec 2016 04:43:49 AM GMT
# gpg: using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>"
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* dgibson/tags/ppc-for-2.8-20161201:
spapr: fix default DRC state for coldplugged LMBs
Message-id: 20161201044441.14365-1-david@gibson.dropbear.id.au
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Currently we set the initial isolation/allocation state for DRCs
associated with coldplugged LMBs to ISOLATED/UNUSABLE,
respectively, under the assumption that the guest will move this
state to UNISOLATED/USABLE.
In fact, this is only the case for LMBs added via hotplug. For
coldplugged LMBs, the guest actually assumes the initial state to
be UNISOLATED/USABLE.
In practice, this only becomes an issue when we attempt to unplug
one of these LMBs, where the guest kernel will issue an
rtas-get-sensor-state call to check that the corresponding DRC is
in an USABLE state before it will release the LMB back to
QEMU. If the returned state is otherwise, the guest will assume no
further action is needed, which bypasses the QEMU-side cleanup that
occurs during the USABLE->UNUSABLE transition. This results in
LMBs and their corresponding pc-dimm devices to stick around
indefinitely.
This patch fixes the issue by manually setting DRCs associated with
cold-plugged LMBs to UNISOLATED/ALLOCATED, but leaving the hotplug
state untouched. As it turns out, this is analogous to the handling
for cold-plugged CPUs in spapr_core_plug().
Cc: qemu-ppc@nongnu.org
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>
Cc: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Though crypto_cfg.reserve is an unused field, let me
initialize the structure in order to make coverity happy.
*** CID 1365923: Uninitialized variables (UNINIT)
/hw/virtio/virtio-crypto.c: 851 in virtio_crypto_get_config()
845 stl_le_p(&crypto_cfg.mac_algo_h, c->conf.mac_algo_h);
846 stl_le_p(&crypto_cfg.aead_algo, c->conf.aead_algo);
847 stl_le_p(&crypto_cfg.max_cipher_key_len, c->conf.max_cipher_key_len);
848 stl_le_p(&crypto_cfg.max_auth_key_len, c->conf.max_auth_key_len);
849 stq_le_p(&crypto_cfg.max_size, c->conf.max_size);
850
>>> CID 1365923: Uninitialized variables (UNINIT)
>>> Using uninitialized value "crypto_cfg". Field "crypto_cfg.reserve"
is uninitialized when calling "memcpy".
[Note: The source code implementation of the function
has been overridden by a builtin model.]
851 memcpy(config, &crypto_cfg, c->config_size);
852 }
853
Rported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
According to ISO C99 / N1256 (referenced in HACKING):
> 6.5.8 Relational operators
>
> 4 For the purposes of these operators, a pointer to an object that is
> not an element of an array behaves the same as a pointer to the first
> element of an array of length one with the type of the object as its
> element type.
>
> 5 When two pointers are compared, the result depends on the relative
> locations in the address space of the objects pointed to. If two
> pointers to object or incomplete types both point to the same object,
> or both point one past the last element of the same array object, they
> compare equal. If the objects pointed to are members of the same
> aggregate object, pointers to structure members declared later compare
> greater than pointers to members declared earlier in the structure,
> and pointers to array elements with larger subscript values compare
> greater than pointers to elements of the same array with lower
> subscript values. All pointers to members of the same union object
> compare equal. If the expression /P/ points to an element of an array
> object and the expression /Q/ points to the last element of the same
> array object, the pointer expression /Q+1/ compares greater than /P/.
> In all other cases, the behavior is undefined.
Our AddressSpace objects are allocated generally individually, and kept in
the "address_spaces" linked list, so we mustn't compare their addresses
with relops.
Convert the pointers subjected to the relop in rom_order_compare() to
"uintptr_t":
> 7.18.1.4 Integer types capable of holding object pointers
>
> 1 [...]
>
> The following type designates an unsigned integer type with the
> property that any valid pointer to void can be converted to this type,
> then converted back to pointer to void, and the result will compare
> equal to the original pointer:
>
> /uintptr_t/
>
> These types are optional.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Fixes: 3e76099aac
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* Commit 3e76099aac ("loader: Allow a custom AddressSpace when loading
ROMs") introduced the "Rom.as" field:
(1) It modified the utility callers of rom_insert() to take "as" as a
new parameter from *their* callers, and set "rom->as" from that
parameter. The functions covered were rom_add_file() and
rom_add_elf_program().
(2) It also modified rom_insert() itself, to auto-assign
"&address_space_memory", in case the external caller passed -- and
the utility caller forwarded -- as=NULL.
Except, commit 3e76099aac forgot to update the third utility caller of
rom_insert(), under point (1), namely rom_add_blob().
* Later, commit 5e774eb3bd ("loader: Add AddressSpace loading support
to uImages") added the load_uimage_as() function, and the
rom_add_blob_fixed_as() function-like macro, with the necessary changes
elsewhere to propagate the new "as" parameter to rom_add_blob():
load_uimage_as()
load_uboot_image()
rom_add_blob_fixed_as()
rom_add_blob()
At this point, the signature (and workings) of rom_add_blob() had been
broken already, and the rom_add_blob_fixed_as() macro passed its "_as"
parameter to rom_add_blob() as "callback_opaque". Given that the
"fw_callback" parameter itself was set to NULL (correctly), this did no
additional damage (the opaque arg would never be used), but ultimately
it broke the new functionality of load_uimage_as().
* The load_uimage_as() function would be put to use in one of the later
patches, commit e481a1f63c ("generic-loader: Add a generic loader").
* We can fix this only in a unified patch now. Append "AddressSpace *as"
to the signature of rom_add_blob(), and handle the new parameter. Pass
NULL from all current callers, except from rom_add_blob_fixed_as(),
where "_as" has to be bumped to the proper position.
* Note that rom_add_file() rejects the case when both "mr" and "as" are
passed in as non-NULL. The action that this is apparently supposed to
prevent is the
rom->mr = mr;
assignment (that's the only place where the "mr" parameter is used in
rom_add_file()). In rom_add_blob() though, we have no "mr" parameter,
and the actions done on the fw_cfg branch:
if (fw_file_name && fw_cfg) {
if (mc->rom_file_has_mr) {
data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
mr = rom->mr;
} else {
data = rom->data;
}
reflect those that are performed by rom_add_file() too (with mr==NULL):
if (rom->fw_file && fw_cfg) {
if ((!option_rom || mc->option_rom_has_mr) &&
mc->rom_file_has_mr) {
data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
} else {
data = rom->data;
}
Hence we need no additional restrictions in rom_add_blob().
* Stable is not affected as both problematic commits appeared first in
v2.8.0-rc0.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org
Fixes: 3e76099aac
Fixes: 5e774eb3bd
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
"mask" needs to be inverted before use.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJYPZu6AAoJEH8JsnLIjy/W1IAP/AwV0sWafsSMnWiz/4NVqeh3
Yk2cBtxCBmnq1y+PilLoZBdHui/RumwVuZKaShs3JA1n5CB1AjsVtEVl/6rQM7lv
yymLr32pODuf4eaGwGY09FqTiL0Erlm846zbSDjkiKbTYoKpzRv0PT2iiA6yTnjO
Mrs5nG7kEWdXPZ0ZsJyEyU3+vs7rNg+4N/VfTdPmCrV5DVBvAeCawM6JXHQNc7LV
ER6Y8W9PAu5mYqwekjAW07lPCudytAsOTrbTTO9Sv/+kZUdKEmv7ZHJrPdECCb6N
vcPOYOzKsEvvR8E0YZtuJDK9W4RTakxdlTste+TtW3VSt1Cs0zpvCFytaGuC+Kmq
mhlA4lYLDvaiNOMl09SvIjjxGI7+FO+1XsY7e4rI5PJzOKWZMFOIwQMNxE3B2qUI
dxd6izf7fzF4V5uDDwHTJ8TAiJDSAe6Bkz+vzipQtu5NARl/isbQuIPIGXPkxZln
fkCYA8/7EXrLXqd3khiRqEHS60ZtNgfm4ss8euMlWAgJAz0RLC1d/XhOIxaCQOg3
R/F9UdJAon6mfOgamZs5yzJgaPU6M90g/QipMB3Ub00VODacTiA81QUjZdEgELBB
zvhgeja7qdIvOh9r9heCCuUTmkWRRppmkrKdqFLowZ2aWosISy/UjiPTGdjDdq7Z
LsfYiRXsW94FmNXdKCqg
=3WTz
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'kwolf/tags/for-upstream' into staging
Block layer patches for 2.8.0-rc2
# gpg: Signature made Tue 29 Nov 2016 03:16:10 PM GMT
# gpg: using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* kwolf/tags/for-upstream:
docs: Specify that cache-clean-interval is only supported in Linux
qcow2: Remove stale comment
qcow2: Allow 'cache-clean-interval' in Linux only
qcow2: Make qcow2_cache_table_release() work only in Linux
Message-id: 1480436227-2211-1-git-send-email-kwolf@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Building qemu fails in distributions where gcc enables PIE by default
(e.g. Debian unstable) with:
/usr/bin/ld: -r and -pie may not be used together
You have to use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
when PIE is enabled and a relocatable object is passed. However, clang
does not know about -r, so try -Wl,-r first.
[This is a fix for commit c96f0ee6a6
("rules.mak: Use -r instead of -Wl, -r to fix building when PIE is
default") which mostly worked but broke the ./configure --enable-modules
build with clang.
--Stefan]
Reported-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20161129153720.29747-1-pbonzini@redhat.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQExBAABCAAbBQJYPFEQFBxwYm9uemluaUByZWRoYXQuY29tAAoJEL/70l94x66D
yF4H/3oBEgzDF9HbnSklknGhkPnOvYnNVKtJbHgk4SnZ1FlPSJLohuz15mXxbr+R
0MzWyQliHiBsAX8sMdvVVHm6YVy9JSABnsefhPUgM++1gT3+EhFsToZ9cWsAYOp7
Q4/hMc66ne0N5SWKjTlCzHfBxw3sPDvOoNYSVYjJYeASTSDQuyyVxRRWMYBFSUnD
p4m7dJCz+my8YXz6diTY8csxFRGmt49EtxtQBU1wBrFc+m8qn4UKaTXoqfcDEBe6
RceS9OAWrddv1Ds4OM/ZgD0BikYehYYnq9THvjWuqhTjHdKKYNeZAodqFJicEZmF
aAIZmhTASQo4fHuImtUja5ggYtU=
=Ht4d
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging
Small fixes for rc2.
# gpg: Signature made Mon 28 Nov 2016 03:45:20 PM GMT
# gpg: using RSA key 0xBFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* bonzini/tags/for-upstream:
rules.mak: Use -r instead of -Wl, -r to fix building when PIE is default
migration/pcspk: Turn migration of pcspk off for 2.7 and older
migration/pcspk: Add a property to state if pcspk is migrated
pci-assign: sync MSI/MSI-X cap and table with PCIDevice
megasas: clean up and fix request completion/cancellation
megasas: do not call pci_dma_unmap after having freed the frame once
Message-id: 1480372837-109736-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
An hbitmap's granularity may be anything from 0 to 63, so when shifting
constants by its value, they should not be plain ints.
Even having changed the types, hbitmap_serialization_granularity() still
tries to shift 64 to the right by the granularity. This operation is
undefined if the granularity is greater than 57. Adding an assertion is
fine for now, because serializing is done only in tests so far, but this
means that only bitmaps with a granularity below 58 can be serialized
and we should thus add a hbitmap_is_serializable() function later.
One of the two places touched in this patch uses
QEMU_ALIGN_UP(x, 1 << y). We can use ROUND_UP() there, since the second
parameter is obviously a power of two.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20161115224732.1334-1-mreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
The detection program needs to be linked with -ldl to build succesfully
with recent versions of LTTng-UST.
We also need to add -ldl to the libs required to build the LTTng-UST
backend (lttng_ust_libs).
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Message-id: 1480348337-24271-1-git-send-email-francis.deslauriers@efficios.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* hw/arm/boot: fix crash handling device trees with no /chosen
or /memory nodes
* generic-loader: only set PC if a CPU is specified
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJYPDVpAAoJEDwlJe0UNgze/WIQAKctEMKR/ct7S8AuEqzW6917
3x0lObOiEsogQAZX2kqo49/9d5H74/T1qVSgMAKRotcGdos3a2igj3dNOy+/mrvk
s2fsKLZri95tNSlHGS8A2E+SCUvynzpzG52vI/S+oAcx0/zKpD/GAUCcRDatQP7o
va/eMlbditeAG6Y8qaHafgrfgxlm0kQpywtli2ZMaaJz7kMmid8dfGqPm1sJFk8S
lxIJVsy5e/g8sQn/bR2i5RcE5Q+e6VAnwYifzi3YKPNPl+YHy0P8J99mXQ6kAPke
uxybd60c2isvqxRzGceNRNkVmati2wyHHH0lXY4p2Mf25FqkcWyCZHqg1/kNX1Ox
YBmYl01YQCCgTRCbw1qyjGq9F2R6RZbJdmtwiiVwUz/hbK/KHclrGeUVNh1Dqde+
xVqvxb9dVb02BM/X9k1u/u4AZHYffGJDHQWo2xSBHn8C/R6uVtXlDQ4h56XiU9Ij
eShVv5NiWK1VCSMltU0skzKZkBmLI9sddqBPywWdtgyjabFhq4vmW5MGBHIPIY+B
UKkP+K5sTHd8rjMd9KcTtGj2Q83XLkKTUJQXVQp1ti1wUSHdkqJt0sptxWOEIlaW
QXWHX4FiLniYU+fqj7V1EGld1I9SXncjexgxSKbvxWBEY0eX6eVo/nt19QqHzwcI
EBXbQHZifiSeWtGhKxVP
=7F5K
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161128' into staging
target-arm queue:
* hw/arm/boot: fix crash handling device trees with no /chosen
or /memory nodes
* generic-loader: only set PC if a CPU is specified
# gpg: Signature made Mon 28 Nov 2016 01:47:21 PM GMT
# gpg: using RSA key 0x3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg: aka "Peter Maydell <pmaydell@gmail.com>"
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* pm215/tags/pull-target-arm-20161128:
arm: Create /chosen and /memory devicetree nodes if necessary
generic-loader: file: Only set a PC if a CPU is specified
Message-id: 1480341071-5367-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
There's no point setting fields always receiving the same value on each
iteration, as handle_ioreq() doesn't alter them anyway. Set state and
count once ahead of the loop, drop the redundant clearing of
data_is_ptr, and avoid the meaningless (because count is 1) setting of
df altogether.
Also avoid doing an unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
We should not consume the second slot if it didn't get written yet.
Normal writers - i.e. Xen - would not update write_pointer between the
two writes, but the page may get fiddled with by the guest itself, and
we're better off avoiding to enter an infinite loop in that case.
Reported-by: yanghongke <yanghongke@huawei.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Building qemu fails in distributions where gcc enables PIE by default
(e.g. Debian unstable) with:
/usr/bin/ld: -r and -pie may not be used together
Use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
when PIE is enabled and a relocatable object is passed.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Message-Id: <20161127162817.15144-1-bunk@stusta.de>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
