When changing from chardev-socket (which supports yank) to
chardev-socket again, it fails, because the new chardev attempts
to register a new yank instance. This in turn fails, as there
still is the yank instance from the current chardev. Also,
the old chardev shouldn't unregister the yank instance when it
is freed.
To fix this, now the new chardev only registers a yank instance if
the current chardev doesn't support yank and thus hasn't registered
one already. Also, when the old chardev is freed, it now only
unregisters the yank instance if the new chardev doesn't need it.
If the initialization of the new chardev fails, it still has
chr->handover_yank_instance set and won't unregister the yank
instance when it is freed.
s->registered_yank is always true here, as chardev-change only works
on user-visible chardevs and those are guraranteed to register a
yank instance as they are initialized via
chardev_new()
qemu_char_open()
cc->open() (qmp_chardev_open_socket()).
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Li Zhang <li.zhang@cloud.ionos.com>
Message-Id: <9637888d7591d2971975188478bb707299a1dc04.1617127849.git.lukasstraub2@web.de>
Always pass the id to chardev_new, since it is needed to register
the yank instance for the chardev. Also, after checking that
nothing calls chardev_new with id=NULL, assert() that id!=NULL.
This fixes a crash when using chardev-change to change a chardev
to chardev-socket, which attempts to register a yank instance.
This in turn tries to dereference the NULL-pointer.
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Li Zhang <li.zhang@cloud.ionos.com>
Message-Id: <3e669b6c160aa7278e37c4d95e0445574f96c7b7.1617127849.git.lukasstraub2@web.de>
Move object_property_try_add_child out of chardev_new into it's
callers. This is a preparation for the next patches to fix yank
with the chardev-change case.
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Li Zhang <li.zhang@cloud.ionos.com>
Message-Id: <b2a5092ec681737bc3a21ea16f3c00848b277521.1617127849.git.lukasstraub2@web.de>
Yank now only depends on util and can be always linked in. Also remove
the stubs as they are not needed anymore.
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <997aa12a28c555d8a3b7a363b3bda5c3cf1821ba.1616521341.git.lukasstraub2@web.de>
Remove dependency on qiochannel by removing yank_generic_iochannel and
letting migration and chardev use their own yank function for
iochannel.
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20ff143fc2db23e27cd41d38043e481376c9cec1.1616521341.git.lukasstraub2@web.de>
Now that we merged into one doc, it makes the nav looks nicer.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210323074704.4078381-1-marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
This commit fixes an issue where migration is failing in the load phase
because of a false alarm about data unavailability.
Following is the error received when the amount of data to be transferred
exceeds the default buffer size setup by G_BUFFERED_INPUT_STREAM(4KiB),
even when the maximum data size supported by this backend is 1MiB
(DBUS_VMSTATE_SIZE_LIMIT):
dbus_vmstate_post_load: Invalid vmstate size: 4364
qemu-kvm: error while loading state for instance 0x0 of device 'dbus-vmstate/dbus-vmstate'
This commit sets the size of the input stream buffer used during load to
DBUS_VMSTATE_SIZE_LIMIT which is the maximum amount of data a helper can
send during save phase.
Secondly, this commit makes sure that the input stream buffer is loaded before
checking the size of the data available in it, rectifying the false alarm about
data unavailability.
Fixes: 5010cec2bc ("Add dbus-vmstate object")
Signed-off-by: Priyankar Jain <priyankar.jain@nutanix.com>
Message-Id: <cdaad4718e62bf22fd5e93ef3e252de20da5c17c.1612273156.git.priyankar.jain@nutanix.com>
[ Modified printf format for gsize ]
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
g_hash_table_add always retains ownership of the pointer passed in as
the key. Its return status merely indicates whether the added entry was
new, or replaced an existing entry. Thus key must never be freed after
this method returns.
Spotted by ASAN:
==2407186==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ac4f0 at pc 0x7ffff766659c bp 0x7fffffffd1d0 sp 0x7fffffffc980
READ of size 1 at 0x6020003ac4f0 thread T0
#0 0x7ffff766659b (/lib64/libasan.so.6+0x8a59b)
#1 0x7ffff6bfa843 in g_str_equal ../glib/ghash.c:2303
#2 0x7ffff6bf8167 in g_hash_table_lookup_node ../glib/ghash.c:493
#3 0x7ffff6bf9b78 in g_hash_table_insert_internal ../glib/ghash.c:1598
#4 0x7ffff6bf9c32 in g_hash_table_add ../glib/ghash.c:1689
#5 0x5555596caad4 in module_load_one ../util/module.c:233
#6 0x5555596ca949 in module_load_one ../util/module.c:225
#7 0x5555596ca949 in module_load_one ../util/module.c:225
#8 0x5555596cbdf4 in module_load_qom_all ../util/module.c:349
Typical C bug...
Fixes: 90629122d2 ("module: use g_hash_table_add()")
Cc: qemu-stable@nongnu.org
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210316134456.3243102-1-marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
In an ideal world, we would all get along together very well, always be
polite and never end up in huge conflicts. And even if there are conflicts,
we would always handle each other fair and respectfully. Unfortunately,
this is not an ideal world and sometimes people forget how to interact with
each other in a professional and respectful way. Fortunately, this seldom
happens in the QEMU community, but for such rare cases it is preferrable
to have a basic code of conduct document available to show to people
who are misbehaving. In case that does not help yet, we should also have
a conflict resolution policy ready that can be applied in the worst case.
The Code of Conduct document tries to be short and to the point while
trying to remain friendly and welcoming; it is based on the Fedora Code
of Conduct[1] with extra detail added based on the Contributor Covenant
1.3.0[2]. Other proposals included the Contributor Covenant 1.3.0 itself
or the Django Code of Conduct[3] (which is also a derivative of Fedora's)
but, in any case, there was agreement on keeping the conflict resolution
policy separate from the CoC itself.
An important point is whether to apply the code of conduct to violations
that occur outside public spaces. The text herein restricts that to
individuals acting as a representative or a member of the project or
its community. This is intermediate between the Contributor Covenant
(which only mentions representatives of the community, for example using
an official project e-mail address or posting via an official social media
account), and the Django Code of Conduct, which says that violations of
this code outside these spaces "may" be considered but otherwise applies
no limit.
The conflict resolution policy is based on the Drupal Conflict Resolution
Policy[4] and its derivative, the Mozilla Consequence Ladder[5].
[1] https://www.fedoraproject.com/code-of-conduct/
[2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/
[3] https://www.djangoproject.com/conduct/
[4] https://www.drupal.org/conflict-resolution
[5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md
Co-developed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Python scripts are not inputs, and putting them in @INPUT@. This
puts requirements on the command line format, keeping all inputs
close to the name of the script. Avoid that by not including the
script in the command and not in the inputs.
Also wrap "PYTHONPATH" usage with "env", since setting the environment
this way is not valid under Windows.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
gen_semantics is an executable, not an input. Meson 0.57 special cases
the first argument and @INPUT@ is not expanded there. Fix that by
not including it in the input, only in the command.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit "c87ea11631 configure: add --without-default-features" use
default_feature to set default values for configure option. This value
is used for EXESUF too.
However, EXESUF is not option to be tested, it is just append to any
binary name so using --without-default-features set EXESUF to "n"o and
all binaries using it has form <name>no (e.g. qemu-imgno).
This is not expected behavior as disabling features should not cause
generating different binary names.
Reverting back to setting EXESUF to empty value unless needed otherwise.
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
Message-Id: <20210331081845.105089-1-mrezanin@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds icount handling to mfspr/mtspr instructions
that may deal with hardware timers.
Signed-off-by: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>
Message-Id: <161700376169.1135890.8707223959310729949.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Stafford Horne <shorne@gmail.com>
This patch enables vCPU notification to wake it up
when new async event comes in replay mode.
The motivation of this patch is the following.
Consider recorded block async event. It is saved into the log
with one of the checkpoints. This checkpoint may be passed in
vCPU loop. In replay mode when this async event is read from
the log, and block thread task is not finished yet, vCPU thread
goes to sleep. That is why this patch adds waking up the vCPU
to process this finished event.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161726519158.1476949.7614181684462079836.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch moves static last_delta variable into timers_state
structure to allow correct vmstate operations with icount shift=auto enabled.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161701335066.1180180.7104085247702343395.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This reverts commit 6d9abb6de9.
The real code change had already been added by Kevin's commit da0a932bbf
("hmp: QAPIfy object_add") and commit 6d9abb6d just added a duplicated
include statement as a left-over of a rebase.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210328054758.2351461-1-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Record/replay uses checkpoints to synchronize the execution
of the threads and timers. Hardware events such as BH are
processed at the checkpoints too.
Event processing can cause refreshing the virtual timers
and calling the icount-related functions, that also use checkpoints.
This patch prevents recursive processing of such checkpoints,
because they have their own records in the log and should be
processed later.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161700476500.1140362.10108444973730452257.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ObjectType and ObjectOptions are defined in a target-independent file,
therefore they do not have access to target-specific configuration
symbols such as CONFIG_PSERIES or CONFIG_SEV. For this reason,
pef-guest and sev-guest are currently omitted when compiling the
generated QAPI files. In addition, this causes ObjectType to have
different definitions depending on the file that is including
qapi-types-qom.h (currently this is not causing any issues, but it
is wrong).
Define the two enum entries and the SevGuestProperties type
unconditionally to avoid the issue. We do not expect to have
many target-dependent user-creatable classes, so it is not
particularly problematic.
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These two opcodes only allow a memory operand.
Lacking the check for a register operand, we used the A0 temp
without initialization, which led to a tcg abort.
Buglink: https://bugs.launchpad.net/qemu/+bug/1921138
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210324164650.128608-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 3eacf70bb5 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
This fixes the following compilation failure on Arm-based Macs:
In file included from migration/multifd.c:23:
In file included from migration/tls.h:25:
In file included from include/io/channel-tls.h:26:
In file included from include/crypto/tlssession.h:24:
include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found
#include <gnutls/gnutls.h>
^~~~~~~~~~~~~~~~~
1 error generated.
(as well as for channel.c and tls.c)
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20210320171221.37437-1-jrtc27@jrtc27.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
S390 PCI currently has no backup, add one. Add an additional backup
for vfio-ccw and refresh the backup for vfio-ap.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Jason J. Herne <jjherne@linux.ibm.com>
Acked-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Message-Id: <1616680509-8339-1-git-send-email-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
when executing the following scripts, it throw error message:
$ ./scripts/get_maintainer.pl -f tests/migration/guestperf.py
get_maintainer.pl: No maintainers found, printing recent contributors.
get_maintainer.pl: Do not blindly cc: them on patches! Use common sense.
add the tests/migration to the "Migration" section of MAINTAINERS
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <91d5978357fb8709ef61d2030984f7142847037d.1616141556.git.huangy81@chinatelecom.cn>
Signed-off-by: Thomas Huth <thuth@redhat.com>
A fix for VDI image files and more generally for CoRwlock.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmBkRe8ACgkQnKSrs4Gr
c8g2EAf9Eq81Ve816xZTUc/2FzC0HGKxPehNkdbCBLbX/a+HgYQEUALFP6Lzfvud
D1rF2bcVTpPUdvpW2UebIyQcLqRH80q1Ba9VhuA99FAYeryg+xVcRFLbHgKfticT
omKSc9yrwJgKJXRZodSsggVBPjsCmhfClO0kA4nGLEywmZbr7i1L/fcbUPI68cOr
5Lv19UDjTIgaGCt0oJN9x/W7FKzz53tBOkGKqmQd2ZEq4LmIlObFQq7ZIHRejneU
76PDPiNRM4Y6fotXl91vMjCZykihuf8FYncXWhnHIOdUxUPQge2SCXhRe16bCEVG
y/6keiV9U3CfsSCHuLK85QnBQKrTPg==
=T9vh
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stefanha-gitlab/tags/block-pull-request' into staging
Pull request
A fix for VDI image files and more generally for CoRwlock.
# gpg: Signature made Wed 31 Mar 2021 10:50:39 BST
# gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8
* remotes/stefanha-gitlab/tags/block-pull-request:
test-coroutine: Add rwlock downgrade test
test-coroutine: Add rwlock upgrade test
coroutine-lock: Reimplement CoRwlock to fix downgrade bug
coroutine-lock: Store the coroutine in the CoWaitRecord only once
block/vdi: Don't assume that blocks are larger than VdiHeader
block/vdi: When writing new bmap entry fails, don't leak the buffer
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Here's another set of patches for the ppc target and associated
machine types. I'd hoped to send this closer to the hard freeze, but
got caught up for some time chasing what looked like a strange
regression, before finally concluding it was due to unrelated failures
on the CI.
This is just a handful of fairly straightforward fixes, plus one
performance improvement that's simple and beneficial enough that I'm
considering it a "performance bug fix".
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAmBkFRkACgkQbDjKyiDZ
s5JrbBAAlaiADr4H0nx6XcNXdDCru+ceG1kc9xVMRIg3oSex4hhMkUH4kNqEVAVT
pfekIRlv2I5jlth4ogxHY5SqAJ9/NqZBMT9NxgSoDQAZtSIvW/6PegcdbbcdSnGT
afBYJH/Tw4aqu2K92knTX7meVxlmhcQF/we1tYkUkO1iEfRSSz7Ubdb5QxTbuAch
1aOWg9RPw47DqLsPDnEZ+VLkRZI6m02uFy8Bl4DOM9DuugY+qKrCnWR1wgnWFMty
lbYzKRnoDtrs/ginAY8uzNEonoeAhLOYO1vgAbSE0sastueNhLx4tBhB5Q6Wxw1e
gETP1/a/+RNOIf3ua4zucVcDswqgxw0TPZYIjesn498eFxTggy2au2Rlwkg+lQt1
jS258BFfOPKkL/cmVWC84nVZhIasE3uA6A7A5tQjFEyaAPOijIRwg6nwx46zTTeO
kFZLBoc5T9933sXaXlsj1dB/bSZ0aBPOZBBhL5eIgeLsfTAcJGNfwT8k2qBpWRqn
pX7ZbFvqgUm3bLtY+GIbCa8hHLrmdxfPhfh+J+NrM75lQrjKKBsToDI2fBF+5iIc
UYoRFngqSP0rGq4H/zLlFNjN5J9wYfjKxA4fA+1ghB7LmUSABoOGOCmrLNnjvis6
5iy8CbUZ0fHxoABbma3hb2vaMYgKyxE0pD83v7TysjpyW6IQ9uY=
=jEq4
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210331' into staging
ppc patch queue for 2021-03-31
Here's another set of patches for the ppc target and associated
machine types. I'd hoped to send this closer to the hard freeze, but
got caught up for some time chasing what looked like a strange
regression, before finally concluding it was due to unrelated failures
on the CI.
This is just a handful of fairly straightforward fixes, plus one
performance improvement that's simple and beneficial enough that I'm
considering it a "performance bug fix".
# gpg: Signature made Wed 31 Mar 2021 07:22:17 BST
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dg-gitlab/tags/ppc-for-6.0-20210331:
hw/net: fsl_etsec: Tx padding length should exclude CRC
spapr: Fix typo in the patb_entry comment
spapr: Assert DIMM unplug state in spapr_memory_unplug()
target/ppc/kvm: Cache timebase frequency
hw/ppc: e500: Add missing #address-cells and #size-cells in the eTSEC node
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Test that rwlock upgrade is fair, and that readers go back to sleep if
a writer is in line.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210325112941.365238-6-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
An invariant of the current rwlock is that if multiple coroutines hold a
reader lock, all must be runnable. The unlock implementation relies on
this, choosing to wake a single coroutine when the final read lock
holder exits the critical section, assuming that it will wake a
coroutine attempting to acquire a write lock.
The downgrade implementation violates this assumption by creating a
read lock owning coroutine that is exclusively runnable - any other
coroutines that are waiting to acquire a read lock are *not* made
runnable when the write lock holder converts its ownership to read
only.
More in general, the old implementation had lots of other fairness bugs.
The root cause of the bugs was that CoQueue would wake up readers even
if there were pending writers, and would wake up writers even if there
were readers. In that case, the coroutine would go back to sleep *at
the end* of the CoQueue, losing its place at the head of the line.
To fix this, keep the queue of waiters explicitly in the CoRwlock
instead of using CoQueue, and store for each whether it is a
potential reader or a writer. This way, downgrade can look at the
first queued coroutines and wake it only if it is a reader, causing
all other readers in line to be released in turn.
Reported-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210325112941.365238-5-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When taking the slow path for mutex acquisition, set the coroutine
value in the CoWaitRecord in push_waiter(), rather than both there and
in the caller.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210325112941.365238-4-pbonzini@redhat.com
Message-Id: <20210309144015.557477-4-david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Given that the block size is read from the header of the VDI file, a
wide variety of sizes might be seen. Rather than re-using a block
sized memory region when writing the VDI header, allocate an
appropriately sized buffer.
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Max Reitz <mreitz@redhat.com>
Message-id: 20210325112941.365238-3-pbonzini@redhat.com
Message-Id: <20210309144015.557477-3-david.edmondson@oracle.com>
Acked-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If a new bitmap entry is allocated, requiring the entire block to be
written, avoiding leaking the buffer allocated for the block should
the write fail.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Max Reitz <mreitz@redhat.com>
Message-id: 20210325112941.365238-2-pbonzini@redhat.com
Message-Id: <20210309144015.557477-2-david.edmondson@oracle.com>
Acked-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
As the comment of tx_padding_and_crc() says: "Never add CRC in QEMU",
min_frame_len should excluce CRC, so it should be 60 instead of 64.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210316081505.72898-1-bmeng.cn@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There is no H_REGISTER_PROCESS_TABLE, it is H_REGISTER_PROC_TBL handler
for which is still called h_register_process_table() though.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-Id: <20210225032335.64245-1-aik@ozlabs.ru>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
spapr_memory_unplug() is the last step of the hot unplug sequence.
It is indirectly called by:
spapr_lmb_release()
hotplug_handler_unplug()
and spapr_lmb_release() already buys us that DIMM unplug state is
present : it gets restored with spapr_recover_pending_dimm_state()
if missing.
g_assert() that spapr_pending_dimm_unplugs_find() cannot return NULL
in spapr_memory_unplug() to make this clear and silence Coverity.
Fixes: Coverity CID 1450767
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <161562021166.948373.15092876234470478331.stgit@bahia.lan>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Each vCPU core exposes its timebase frequency in the DT. When running
under KVM, this means parsing /proc/cpuinfo in order to get the timebase
frequency of the host CPU.
The parsing appears to slow down the boot quite a bit with higher number
of cores:
# of cores seconds spent in spapr_dt_cpus()
8 0.550122
16 1.342375
32 2.850316
64 5.922505
96 9.109224
128 12.245504
256 24.957236
384 37.389113
The timebase frequency of the host CPU is identical for all
cores and it is an invariant for the VM lifetime. Cache it
instead of doing the same expensive parsing again and again.
Rename kvmppc_get_tbfreq() to kvmppc_get_tbfreq_procfs() and
rename the 'retval' variable to make it clear it is used as
fallback only. Come up with a new version of kvmppc_get_tbfreq()
that calls kvmppc_get_tbfreq_procfs() only once and keep the
value in a static.
Zero is certainly not a valid value for the timebase frequency.
Treat atoi() returning zero as another parsing error and return
the fallback value instead. This allows kvmppc_get_tbfreq() to
use zero as an indicator that kvmppc_get_tbfreq_procfs() hasn't
been called yet.
With this patch applied:
384 0.518382
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <161600382766.1780699.6787739229984093959.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Per devicetree spec v0.3 [1] chapter 2.3.5:
The #address-cells and #size-cells properties are not inherited
from ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
These properties are currently missing, causing the <reg> property
of the queue-group subnode to be incorrectly parsed using default
values.
[1] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf
Fixes: fdfb7f2cdb ("e500: Add support for eTSEC in device tree")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Message-Id: <20210311081608.66891-1-bmeng.cn@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/display/xlnx_dp: Free FIFOs adding xlnx_dp_finalize()
* hw/arm/smmuv3: Drop unused CDM_VALID() and is_cd_valid()
* target/arm: Make number of counters in PMCR follow the CPU
* hw/timer/renesas_tmr: Add default-case asserts in read_tcnt()
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmBjJlUZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3oWOEACXNbKL+hmbzErBqymWX22Y
vgg9PBSb7TCMgue5nQdxFCPx8D4XSyjqJf/86gOZb4b/7Rx9ltrR+UhTIOESyNZV
WniCXPaUtKFBy93IrrukLtV/ekIAi1cIPfHZBEEwSPUSxqfIgDWz5L74HfeJZVWr
LGZCdvxBZYA8lHvqJZS7QpPjlAngu82CRnW9GEd6cRn3YBP6yIqwgNhcRDtuu3+g
IkjueipA1qLwplixM2tZ2Se2wT6PaKa0esbPb9zs7dmdXSLo5HmPA7xCN+NNPCnR
Bd7dMr82P4A/lXVEwK6ZJFXU0Ooum7BBBCuYS26axJEsn5IJxk2Jusjg0CdN7Roi
hmUI9rQrAVJlmHX7czEeHZ2sM/N1kau98eQu6tb8RuE408rLCASx/VgIBfkxGyIX
cxCgsOmM/GXcZr79eRMTt4rDjPuzmsMRSWM9LlDiDyczRr7jDgqoWgGmWOBTW+Ad
2rUHwaL3PpsP1b56uzVuuSDslj9RV4Q/2Q+hTTzazkGhowYG0XL/D+9PFvC4gk6U
fUqaHOO4tMvA1z6/urpCSta7cM5U0iivZTGoTJgbsBYrUpeL5iOpWSS9GqzV/wID
zTS9jbs9HsijIGawq4kqzqN3zR1avthi2ngAIucPNw0dPrsQ1koNwyAAq3JwSG9G
Bs5ukPXpg+989DVPmbSGgw==
=4GT6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20210330' into staging
* net/npcm7xx_emc.c: Fix handling of receiving packets when RSDR not set
* hw/display/xlnx_dp: Free FIFOs adding xlnx_dp_finalize()
* hw/arm/smmuv3: Drop unused CDM_VALID() and is_cd_valid()
* target/arm: Make number of counters in PMCR follow the CPU
* hw/timer/renesas_tmr: Add default-case asserts in read_tcnt()
# gpg: Signature made Tue 30 Mar 2021 14:23:33 BST
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20210330:
hw/timer/renesas_tmr: Add default-case asserts in read_tcnt()
target/arm: Make number of counters in PMCR follow the CPU
hw/arm/smmuv3: Drop unused CDM_VALID() and is_cd_valid()
hw/display/xlnx_dp: Free FIFOs adding xlnx_dp_finalize()
net/npcm7xx_emc.c: Fix handling of receiving packets when RSDR not set
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
- Mark the qcow2 cache clean timer as external to fix record/replay
- Fix the mirror filter node's permissions so that an external process
cannot grab an image while it is used as the mirror source
- Add documentation about FUSE exports to the storage daemon
- When creating a qcow2 image with the data-file-raw option, all
metadata structures should be preallocated
- iotest fixes
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAmBjG9ASHG1yZWl0ekBy
ZWRoYXQuY29tAAoJEPQH2wBh1c9AVa4H/1NC4aTFi2sMzyQ8hkUck2llPiZdxP4V
KZbyUay+z2pLPWMonyDP6szGv6444lHGBnGQWKZHcw4o5xWNu50jEB2YpkhXS9i1
8shkZNVGxy6CVxinhrFG9qMv7GuoX3vOsVu5HnBjgpM162ZVYR+Af/8erqG1A4js
9odM5Zl6hb+okbSovgucT3UxNeYvBDnhsKzpQnvUvsdJu3RKz6gSlTz+f6jJLLP/
+hK54CDkCpK4fY6W0QLcZcLmmhTHYZXgeKDAHWGAzBH5p3ARY6uAXGZ9+fLE88X4
fhgcuYeLMS+sJCzGXnEDAmGebGhEOzszvskBRIHdWK861zg0RssWQP4=
=BdFo
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2021-03-30' into staging
Block patches for 6.0-rc1:
- Mark the qcow2 cache clean timer as external to fix record/replay
- Fix the mirror filter node's permissions so that an external process
cannot grab an image while it is used as the mirror source
- Add documentation about FUSE exports to the storage daemon
- When creating a qcow2 image with the data-file-raw option, all
metadata structures should be preallocated
- iotest fixes
# gpg: Signature made Tue 30 Mar 2021 13:38:40 BST
# gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg: issuer "mreitz@redhat.com"
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2021-03-30:
iotests/244: Test preallocation for data-file-raw
qcow2: Force preallocation with data-file-raw
qsd: Document FUSE exports
block/mirror: Fix mirror_top's permissions
iotests/046: Filter request length
qcow2: use external virtual timers
iotests/116: Fix reference output
iotests: fix 051.out expected output after error text touchups
iotests: Fix typo in iotest 051
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In commit 81b3ddaf87 we fixed a use of uninitialized data
in read_tcnt(). However this change wasn't enough to placate
Coverity, which is not smart enough to see that if we read a
2 bit field and then handle cases 0, 1, 2 and 3 then there cannot
be a flow of execution through the switch default. Add explicit
default cases which assert that they can't be reached, which
should help silence Coverity.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210319162458.13760-1-peter.maydell@linaro.org
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of having a single PMCR_NUM_COUNTERS, make each CPU type
specify the PMCR reset value (obtained from the appropriate TRM), and
use the 'N' field of that value to define the number of counters
provided.
This means that we now supply 6 counters for Cortex-A53, A57, A72,
A15 and A9 as well as '-cpu max'; Cortex-A7 and A8 stay at 4; and
Cortex-R5 goes down to 3.
Note that because we now use the PMCR reset value of the specific
implementation, we no longer set the LC bit out of reset. This has
an UNKNOWN value out of reset for all cores with any AArch32 support,
so guest software should be setting it anyway if it wants it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Message-id: 20210311165947.27470-1-peter.maydell@linaro.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
They were introduced in commit 9bde7f0674 ("hw/arm/smmuv3: Implement
translate callback") but never actually used. Drop them.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Acked-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20210325142702.790-1-yuzenghui@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When building with --enable-sanitizers we get:
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x5618479ec7cf in malloc (qemu-system-aarch64+0x233b7cf)
#1 0x7f675745f958 in g_malloc (/lib64/libglib-2.0.so.0+0x58958)
#2 0x561847c2dcc9 in xlnx_dp_init hw/display/xlnx_dp.c:1259:5
#3 0x56184a5bdab8 in object_init_with_type qom/object.c:375:9
#4 0x56184a5a2bda in object_initialize_with_type qom/object.c:517:5
#5 0x56184a5a24d5 in object_initialize qom/object.c:536:5
#6 0x56184a5a2f6c in object_initialize_child_with_propsv qom/object.c:566:5
#7 0x56184a5a2e60 in object_initialize_child_with_props qom/object.c:549:10
#8 0x56184a5a3a1e in object_initialize_child_internal qom/object.c:603:5
#9 0x5618495aa431 in xlnx_zynqmp_init hw/arm/xlnx-zynqmp.c:273:5
The RX/TX FIFOs are created in xlnx_dp_init(), add xlnx_dp_finalize()
to destroy them.
Fixes: 58ac482a66 ("introduce xlnx-dp")
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210323182958.277654-1-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Three test cases:
(1) Adding a qcow2 (metadata) file to an existing data file, see whether
we can read the existing data through the qcow2 image.
(2) Append data to the data file, grow the qcow2 image accordingly, see
whether we can read the new data through the qcow2 image.
(3) At runtime, add a backing image to a freshly created qcow2 image
with an external data file (with data-file-raw). Reading data from
the qcow2 image must return the same result as reading data from the
data file, so everything in the backing image must be ignored.
(This did not use to be the case, because without the L2 tables
preallocated, all clusters would appear as unallocated, and so the
qcow2 driver would fall through to the backing file.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20210326145509.163455-3-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Setting the qcow2 data-file-raw bit means that you can ignore the
qcow2 metadata when reading from the external data file. It does not
mean that you have to ignore it, though. Therefore, the data read must
be the same regardless of whether you interpret the metadata or whether
you ignore it, and thus the L1/L2 tables must all be present and give a
1:1 mapping.
This patch changes 244's output: First, the qcow2 file is larger right
after creation, because of metadata preallocation. Second, the qemu-img
map output changes: Everything that was not explicitly discarded or
zeroed is now a data area.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20210326145509.163455-2-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
getsockopt(fd, SOL_NETLINK, NETLINK_LIST_MEMBERSHIPS, *optval, *optlen)
syscall allows optval to be NULL/invalid if optlen points to a size of
zero. This allows userspace to query the length of the array they should
use to get the full membership list before allocating memory for said
list, then re-calling getsockopt with proper optval/optlen arguments.
Notable users of this pattern include systemd-networkd, which in the
(albeit old) version 237 tested, cannot start without this fix.
Signed-off-by: Frédéric Fortier <frf@ghgsat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20210328180135.88449-1-frf@ghgsat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Max noticed that since blk_aio_pwrite_zeroes() may invoke the callback
before returning, the callbacks will never see *count == 0 and thus
never free the count variable or decrement num_formats causing a CQE to
never be posted.
Coverity (CID 1451082) also picked up on the fact that count would not
be free'ed if the namespace was of zero size.
Fix both of these issues by explicitly checking *count and finalize for
the given namespace if --(*count) is zero. Enqueing a CQE if there are
no AIOs outstanding after this case is already handled by nvme_format()
by inspecting *num_formats.
Reported-by: Max Reitz <mreitz@redhat.com>
Reported-by: Coverity (CID 1451082)
Fixes: dc04d25e2f ("hw/block/nvme: add support for the format nvm command")
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Reviewed-by: Gollu Appalanaidu <anaidu.gollu@samsung.com>
