Currently, scsi_get_configuration always returns a current
profile (DVD or CD), even when there is actually no media present.
By comparison, ide/atapi uses a default profile of 0 (MMC_PROFILE_NONE)
for this case and checks for tray_open, so let's do the same for scsi.
This fixes a problem I'm seeing with Fedora 22 guests where systemd
cdrom_id fails to unmount after a QEMU-initiated eject against a
scsi cdrom device because it believes the media is still present
(but unreadable).
Signed-off-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Message-Id: <1436986352-10695-1-git-send-email-mjrosato@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is a guest-triggerable buffer overflow present in QEMU 2.2.0
and newer. scsi_cdb_length returns -1 as an error value, but the
caller does not check it.
Luckily, the massive overflow means that QEMU will just SIGSEGV,
making the impact much smaller.
Reported-by: Zhu Donghai (朱东海) <donghai.zdh@alibaba-inc.com>
Fixes: 1894df0281
Reviewed-by: Fam Zheng <famz@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If vnc's password is configured, it will leak memory
which cipher variable pointed on every vnc connection.
Cc: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Message-Id: <1437556133-11268-1-git-send-email-arei.gonglei@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 812c1057 introduced HUP detection on unix and tcp sockets prior
to a read in tcp_chr_read. This unfortunately broke CloudStack 4.2
which relied on the old behaviour where data on a socket was readable
even if a HUP was present.
A working solution is to properly check the return values from recv,
handling a closed socket once there is no more data to read.
Also enable polling for G_IO_NVAL to ensure the callback is called
for all possible events as these should now be possible to handle
with the improved error detection.
Signed-off-by: Nils Carlson <pyssling@ludd.ltu.se>
Message-Id: <1437338396-22336-1-git-send-email-pyssling@ludd.ltu.se>
[Do not handle EINTR; use socket_error(). - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When accessing the dispatch pointer in an AddressSpace within an RCU
critical section we should always use atomic_rcu_read(). Fix an
access within memory_region_section_get_iotlb() which was incorrectly
doing a direct pointer access.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <1437391637-31576-1-git-send-email-peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It is pretty rare for aio_notify to actually set the EventNotifier. It
can happen with worker threads such as thread-pool.c's, but otherwise it
should never be set thanks to the ctx->notify_me optimization. The
previous patch, unfortunately, added an unconditional call to
event_notifier_test_and_clear; now add a userspace fast path that
avoids the call.
Note that it is not possible to do the same with event_notifier_set;
it would break, as proved (again) by the included formal model.
This patch survived over 3000 reboots on aarch64 KVM.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-7-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
event_notifier_test_and_clear must be called before processing events.
Otherwise, an aio_poll could "eat" the notification before the main
I/O thread invokes ppoll(). The main I/O thread then never wakes up.
This is an example of what could happen:
i/o thread vcpu thread worker thread
---------------------------------------------------------------------
lock_iothread
notify_me = 1
...
unlock_iothread
bh->scheduled = 1
event_notifier_set
lock_iothread
notify_me = 3
ppoll
notify_me = 1
aio_dispatch
aio_bh_poll
thread_pool_completion_bh
bh->scheduled = 1
event_notifier_set
node->io_read(node->opaque)
event_notifier_test_and_clear
ppoll
*** hang ***
"Tracing" with qemu_clock_get_ns shows pretty much the same behavior as
in the previous bug, so there are no new tricks here---just stare more
at the code until it is apparent.
One could also use a formal model, of course. The included one shows
this with three processes: notifier corresponds to a QEMU thread pool
worker, temporary_waiter to a VCPU thread that invokes aio_poll(),
waiter to the main I/O thread. I would be happy to say that the
formal model found the bug for me, but actually I wrote it after the
fact.
This patch is a bit of a big hammer. The next one optimizes it,
with help (this time for real rather than a posteriori :)) from
another, similar formal model.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-6-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This patch rewrites the ctx->dispatching optimization, which was the cause
of some mysterious hangs that could be reproduced on aarch64 KVM only.
The hangs were indirectly caused by aio_poll() and in particular by
flash memory updates's call to blk_write(), which invokes aio_poll().
Fun stuff: they had an extremely short race window, so much that
adding all kind of tracing to either the kernel or QEMU made it
go away (a single printf made it half as reproducible).
On the plus side, the failure mode (a hang until the next keypress)
made it very easy to examine the state of the process with a debugger.
And there was a very nice reproducer from Laszlo, which failed pretty
often (more than half of the time) on any version of QEMU with a non-debug
kernel; it also failed fast, while still in the firmware. So, it could
have been worse.
For some unknown reason they happened only with virtio-scsi, but
that's not important. It's more interesting that they disappeared with
io=native, making thread-pool.c a likely suspect for where the bug arose.
thread-pool.c is also one of the few places which use bottom halves
across threads, by the way.
I hope that no other similar bugs exist, but just in case :) I am
going to describe how the successful debugging went... Since the
likely culprit was the ctx->dispatching optimization, which mostly
affects bottom halves, the first observation was that there are two
qemu_bh_schedule() invocations in the thread pool: the one in the aio
worker and the one in thread_pool_completion_bh. The latter always
causes the optimization to trigger, the former may or may not. In
order to restrict the possibilities, I introduced new functions
qemu_bh_schedule_slow() and qemu_bh_schedule_fast():
/* qemu_bh_schedule_slow: */
ctx = bh->ctx;
bh->idle = 0;
if (atomic_xchg(&bh->scheduled, 1) == 0) {
event_notifier_set(&ctx->notifier);
}
/* qemu_bh_schedule_fast: */
ctx = bh->ctx;
bh->idle = 0;
assert(ctx->dispatching);
atomic_xchg(&bh->scheduled, 1);
Notice how the atomic_xchg is still in qemu_bh_schedule_slow(). This
was already debated a few months ago, so I assumed it to be correct.
In retrospect this was a very good idea, as you'll see later.
Changing thread_pool_completion_bh() to qemu_bh_schedule_fast() didn't
trigger the assertion (as expected). Changing the worker's invocation
to qemu_bh_schedule_slow() didn't hide the bug (another assumption
which luckily held). This already limited heavily the amount of
interaction between the threads, hinting that the problematic events
must have triggered around thread_pool_completion_bh().
As mentioned early, invoking a debugger to examine the state of a
hung process was pretty easy; the iothread was always waiting on a
poll(..., -1) system call. Infinite timeouts are much rarer on x86,
and this could be the reason why the bug was never observed there.
With the buggy sequence more or less resolved to an interaction between
thread_pool_completion_bh() and poll(..., -1), my "tracing" strategy was
to just add a few qemu_clock_get_ns(QEMU_CLOCK_REALTIME) calls, hoping
that the ordering of aio_ctx_prepare(), aio_ctx_dispatch, poll() and
qemu_bh_schedule_fast() would provide some hint. The output was:
(gdb) p last_prepare
$3 = 103885451
(gdb) p last_dispatch
$4 = 103876492
(gdb) p last_poll
$5 = 115909333
(gdb) p last_schedule
$6 = 115925212
Notice how the last call to qemu_poll_ns() came after aio_ctx_dispatch().
This makes little sense unless there is an aio_poll() call involved,
and indeed with a slightly different instrumentation you can see that
there is one:
(gdb) p last_prepare
$3 = 107569679
(gdb) p last_dispatch
$4 = 107561600
(gdb) p last_aio_poll
$5 = 110671400
(gdb) p last_schedule
$6 = 110698917
So the scenario becomes clearer:
iothread VCPU thread
--------------------------------------------------------------------------
aio_ctx_prepare
aio_ctx_check
qemu_poll_ns(timeout=-1)
aio_poll
aio_dispatch
thread_pool_completion_bh
qemu_bh_schedule()
At this point bh->scheduled = 1 and the iothread has not been woken up.
The solution must be close, but this alone should not be a problem,
because the bottom half is only rescheduled to account for rare situations
(see commit 3c80ca1, thread-pool: avoid deadlock in nested aio_poll()
calls, 2014-07-15).
Introducing a third thread---a thread pool worker thread, which
also does qemu_bh_schedule()---does bring out the problematic case.
The third thread must be awakened *after* the callback is complete and
thread_pool_completion_bh has redone the whole loop, explaining the
short race window. And then this is what happens:
thread pool worker
--------------------------------------------------------------------------
<I/O completes>
qemu_bh_schedule()
Tada, bh->scheduled is already 1, so qemu_bh_schedule() does nothing
and the iothread is never woken up. This is where the bh->scheduled
optimization comes into play---it is correct, but removing it would
have masked the bug.
So, what is the bug?
Well, the question asked by the ctx->dispatching optimization ("is any
active aio_poll dispatching?") was wrong. The right question to ask
instead is "is any active aio_poll *not* dispatching", i.e. in the prepare
or poll phases? In that case, the aio_poll is sleeping or might go to
sleep anytime soon, and the EventNotifier must be invoked to wake
it up.
In any other case (including if there is *no* active aio_poll at all!)
we can just wait for the next prepare phase to pick up the event (e.g. a
bottom half); the prepare phase will avoid the blocking and service the
bottom half.
Expressing the invariant with a logic formula, the broken one looked like:
!(exists(thread): in_dispatching(thread)) => !optimize
or equivalently:
!(exists(thread):
in_aio_poll(thread) && in_dispatching(thread)) => !optimize
In the correct one, the negation is in a slightly different place:
(exists(thread):
in_aio_poll(thread) && !in_dispatching(thread)) => !optimize
or equivalently:
(exists(thread): in_prepare_or_poll(thread)) => !optimize
Even if the difference boils down to moving an exclamation mark :)
the implementation is quite different. However, I think the new
one is simpler to understand.
In the old implementation, the "exists" was implemented with a boolean
value. This didn't really support well the case of multiple concurrent
event loops, but I thought that this was okay: aio_poll holds the
AioContext lock so there cannot be concurrent aio_poll invocations, and
I was just considering nested event loops. However, aio_poll _could_
indeed be concurrent with the GSource. This is why I came up with the
wrong invariant.
In the new implementation, "exists" is computed simply by counting how many
threads are in the prepare or poll phases. There are some interesting
points to consider, but the gist of the idea remains:
1) AioContext can be used through GSource as well; as mentioned in the
patch, bit 0 of the counter is reserved for the GSource.
2) the counter need not be updated for a non-blocking aio_poll, because
it won't sleep forever anyway. This is just a matter of checking
the "blocking" variable. This requires some changes to the win32
implementation, but is otherwise not too complicated.
3) as mentioned above, the new implementation will not call aio_notify
when there is *no* active aio_poll at all. The tests have to be
adjusted for this change. The calls to aio_notify in async.c are fine;
they only want to kick aio_poll out of a blocking wait, but need not
do anything if aio_poll is not running.
4) nested aio_poll: these just work with the new implementation; when
a nested event loop is invoked, the outer event loop is never in the
prepare or poll phases. The outer event loop thus has already decremented
the counter.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Preparatory bugfixes and tweaks to the loop before the next patch:
- disable dispatch optimization during aio_prepare. This fixes a bug.
- do not modify "blocking" until after the first WaitForMultipleObjects
call. This is needed in the next patch.
- change the loop to do...while. This makes it obvious that the loop
is always entered at least once. In the next patch this is important
because the first iteration undoes the ctx->notify_me increment that
happened before entering the loop.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-4-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
In these tests, the purpose of the initial calls to aio_poll and
g_main_context_iteration is simply to put the AioContext in a
known state; the return value of the function does not really
matter. The next patch will change those return values; change
the assertions to a while loop which expresses the intention
better.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-3-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The normal value for the event is to be set. If we do not do
this, pause_all_vcpus (through qemu_clock_enable) hangs unless
timerlist_run_timers has been run at least once for the timerlist.
This can happen with the following patches, that make aio_notify do
nothing most of the time.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-2-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Limiting to sectors_per_chunk for each bdrv_is_allocated_above is slow,
because the underlying protocol driver would issue much more queries
than necessary. We should coalesce the query.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: <1436413678-7114-4-git-send-email-famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Small fix to correct schema versioning annotations for recently-added
GuestDiskBusType enum values. Not the end of the world, but ideally
this inconsistency would be corrected prior to 2.4 release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVrqDcAAoJEDNTyc7xCLWEwtAIAJGboUmK4/8yk/6wgvUZnMn7
L/4my7NYKjRWPXcwqzDIht+PTn9/9EtIiqQBEUSADEmylTQjPjxge6Y/ypQBGjLl
0gxfwD5yiBZOhcfEPTOEpQ4sLjpI/63tnhjVw3TacPpbtsVd/BAsGb8tDac7Jsmq
/KH5TGfHSP7C82fzqr9Ei4Wzvk3Hao8hLVzSH6Cc7P/m3sOHNjc5+7CEPxIBcpkp
1DzDv+ioSRnDpKjN0L+E6b4uGX8mfRSFu/GyMie7PBrv85mAPGZbZ/WG4kkKCEPA
EWIjHrqFEabXGzhK1Tp+YrMqlEYjiyaRg6XtNwqbYGqEVvXD1T75mrp7dE/jiCQ=
=5udU
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2015-07-21-tag' into staging
tag for qga-pull-2015-07-21
Small fix to correct schema versioning annotations for recently-added
GuestDiskBusType enum values. Not the end of the world, but ideally
this inconsistency would be corrected prior to 2.4 release.
# gpg: Signature made Tue Jul 21 20:43:24 2015 BST using RSA key ID F108B584
# gpg: Good signature from "Michael Roth <flukshun@gmail.com>"
# gpg: aka "Michael Roth <mdroth@utexas.edu>"
# gpg: aka "Michael Roth <mdroth@linux.vnet.ibm.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584
* remotes/mdroth/tags/qga-pull-2015-07-21-tag:
qga: fixed versions for guest bus types in qapi-schema
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
*added semi-colon to better delineate 2.2 vs. 2.4 versioning
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
* don't sync CNTVCT with kernel all the time (fixes VM time weirdnesses)
* fix a warning compiling disas/arm-a64 with -Wextra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJVrinVAAoJEDwlJe0UNgzexIYP/R1/0+gf5176j9c6JV0UV/ly
zTfkupOWoigI5htZeGTyJmG8sGVIElpPjiewXwyGWXND0k+q8v/6KXuUJ38WrqZ7
T/vYIyyqHYR87g3dQKLq8kvtwlI74Zn2cXxENgF0XinHfs49dwyAkQsbR3VexvQm
VQiIS8ANLMK70SPjJcs8QwPRphfB7uljS7YktKRxsU993NXpN1YoTeFpfadTKbx8
nspB7e/XyMoj2rEO64gq9oOyGsKn+Ls9M6/UwjeTOFe4ceRZ2g4WVCYy8hM+kWe/
Xrb310CzbL8zInlfWCiL8ywBd9cUZ7Jpz2N/A95jhkXc1ZFqAz/WfrjXXzsWn4r3
+fYZEZ6i8DgIMA9rakAPxtdErWmeAFrYGMTGsQ3oa1GbG1AqFFOzRAdSz/t8GVEp
FbuqnUZVignzqYbcmhEuP2Q3IOlLiLMOR7u8C+cT2rr8SSEjj4vgURpKVLr//nLJ
tvJJF/ZbKuJaHPVUNDMk893TEkj5UnHhmM0dzy8bEtzIPLf3zhwD4ev0wBFB+zvj
YbCAifu3PI1oroIfvwZ/wBT+dSWqyodWU3x55PVJS8OegEJPsyQjiRjSJBO78Dx0
EOQhQR4QWIhNw+tymO1T+Xy614SI/3yj/9CWEgdlGC5SHmvq8XWnm7oM0Etcgpb1
8UKnl7If+Dgg4svok+EE
=oVzg
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150721' into staging
target-arm queue:
* don't sync CNTVCT with kernel all the time (fixes VM time weirdnesses)
* fix a warning compiling disas/arm-a64 with -Wextra
# gpg: Signature made Tue Jul 21 12:15:33 2015 BST using RSA key ID 14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
* remotes/pmaydell/tags/pull-target-arm-20150721:
disas/arm-a64: Add missing compiler attribute GCC_FMT_ATTR
target-arm: kvm: Differentiate registers based on write-back levels
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Type fprintf_function which fits here was defined with this attribute.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1437208027-14584-1-git-send-email-sw@weilnetz.de
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some registers like the CNTVCT register should only be written to the
kernel as part of machine initialization or on vmload operations, but
never during runtime, as this can potentially make time go backwards or
create inconsistent time observations between VCPUs.
Introduce a list of registers that should not be written back at runtime
and check this list on syncing the register state to the KVM state.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Message-id: 1437046488-10773-1-git-send-email-christoffer.dall@linaro.org
[PMM: tweaked a few comments, added the new argument to the stub
write_list_to_kvmstate() in target-arm/kvm-stub.c]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Version: GnuPG v1
iQIcBAABAgAGBQJVrT14AAoJEH3vgQaq/DkOq7EP/0yHGzrIM7wKCPEgZWSuzvJF
g2ooc2d669ulLqhRicUuwIGpYgT7WpVrHMxDbw+f3Y02Upyov44l8bG82hmC/1r+
NAbpkl7PZHD7PM/duKtuclPIAmdpXXQoy7mHtb8PG71poaAhC1D8t0Swy1wKPn6r
uhrhySpN2B+yV9P5sNWdxVTd14oHpJhLsTo/YRe+ptgZnqeWyG6+Rz9xX0nMqaLA
8byl4fGUJ8SGxcyV6NKeUK16wXb7HH9d7EaRihnYoxT50DeJb+8NKWcrwfgzd9hu
M+suPJBbenQ6JcT8mDaOsM1/lsWLUJ+561QS3opx3j2kDrtK/sHKf2flZkGp1Ev9
QioEdL9m731/8wIITWIKntzCw4h2nO+ovnQFIzvcni+PaehZrvF5VIC7QLOSZhy6
zqu+E3PY0PkheqXv8/KWOWs+MctfyfotpCtcD7esQ/f9fD4MsFn1NFaDxG6gnWUt
wYytkxhqvCiOy5dGumcyOC7VDdILB4FObSe15H3LUqSfVqIMoFQ6q7Pr+RC84JPE
cosVoRWd/EE8dxqAP0NmARZwdExIRInfg1ZrooteQy9JQvmgaVReqY6diK9SZVtm
1Aue2qBr8im6sxxz4uzwi5Oi8vvB/Y88EV2mBkaDN0oRWQYzj39AX1vebW+vMjJi
GdtqqEIxSNb2mH4vcB0r
=GHN/
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging
# gpg: Signature made Mon Jul 20 19:27:04 2015 BST using RSA key ID AAFC390E
# gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB
# Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E
* remotes/jnsnow/tags/ide-pull-request:
tests: Fix broken targets check-report-qtest-*
ahci: Force ICC bits in PxCMD to zero
qtest/ide: add another short PRDT test flavor
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
They need QTEST_QEMU_IMG. Without it, the tests raise an assertion:
$ make -C bin check-report-qtest-i386.xml
make: Entering directory 'bin'
GTESTER check-report-qtest-i386.xml
blkdebug: Suspended request 'A'
blkdebug: Resuming request 'A'
ahci-test: tests/libqos/libqos.c:162:
mkimg: Assertion `qemu_img_path' failed.
main-loop: WARNING: I/O thread spun for 1000 iterations
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 1437231284-17455-1-git-send-email-sw@weilnetz.de
Signed-off-by: John Snow <jsnow@redhat.com>
Since commit 6e99c63 "net/socket: Drop net_socket_can_send" and friends,
net queues need to be explicitly flushed after qemu_can_send_packet()
returns false, because the netdev side will disable the polling of fd.
This fixes the case of "cont" after "stop" (or migration).
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 1436232067-29144-1-git-send-email-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
True is the default.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Message-id: 1435734647-8371-4-git-send-email-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
True is the default.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Message-id: 1435734647-8371-3-git-send-email-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
True is the default.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Message-id: 1435734647-8371-2-git-send-email-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Convert partially summed packets to be fully checksummed.
In case csum offloaded packet, vmxnet3 implementation always passes an
RxCompDesc with the "Checksum calculated and found correct" notification
to the OS. This emulates the observed ESXi behavior.
Therefore, if packet has the NEEDS_CSUM bit set, we must calculate and
place a fully computed checksum into the tcp/udp header. Otherwise, the
OS driver will receive a checksum-correct indication but with the actual
tcp/udp checksum field having just the pseudo header csum value.
If host OS performs forwarding, it will forward an incorrectly
checksummed packet.
Signed-off-by: Dana Rubin <dana.rubin@ravellosystems.com>
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Message-id: 1436864116-19154-3-git-send-email-shmulik.ladkani@ravellosystems.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Separate RX packet protocol parsing out of 'vmxnet_rx_pkt_attach_data'.
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Message-id: 1436864116-19154-2-git-send-email-shmulik.ladkani@ravellosystems.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
We should pass the size of packet instead of the remaining to
qemu_send_packet_async().
Fixes: 6e99c631f1
("net/socket: Drop net_socket_can_send")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1436259656-24263-1-git-send-email-jasowang@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The AHCI spec requires that the HBA sets the ICC bits to zero after the
ICC change is done. Since we don't do any ICC change, force the bits to
zero all the time.
This fixes delays with some OSs (e.g. OpenBSD) waiting for the ICC bits
to change to 0.
Signed-off-by: Stefan Fritsch <sf@sfritsch.de>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: E1ZFpg7-00027N-HW@eru.sfritsch.de
Signed-off-by: John Snow <jsnow@redhat.com>
The existing short PRDT test case does not transfer any data because the
first PRD is less than 1 sector.
This patch adds another short PRDT test case where the first sector can
be read but the PRDT is still smaller than the requested number of
sectors. This exercises a different code path in ide_dma_cb().
Cc: John Snow <jsnow@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 1435770571-9906-1-git-send-email-stefanha@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Commit e0cf11f31c ("timer: Use a single
definition of NSEC_PER_SEC for the whole codebase") renamed
NANOSECONDS_PER_SECOND to NSEC_PER_SEC.
On Mac OS X there is a <dispatch/time.h> system header which also
defines NSEC_PER_SEC. This causes compiler warnings.
Let's use the old name instead. It's longer but it doesn't clash.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1436364609-7929-1-git-send-email-stefanha@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The only notable thing here is vhost-user multiqueue
revert. We'll work on making it stable in 2.5,
reverting now means we won't have to maintain
bug for bug compability forever.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVrNpQAAoJECgfDbjSjVRp5EwH/jh1iiTG4iXDbSnxPJ/FWwJt
9hgd+GeNT9K5Dc1A+X6d80OdeaH5bjFNqfUXSrIsLKDWYtj01AU2+dgGS3j0/Uv1
FRrrWsnN5idcYuqlznk7X9Eu2mb7npGZnjF4PmDU5Hq5eRj/mgJbWvKYqMolLYtv
cuSHxhbA3dlUTIjfXccMF94kvFQUpfs2A3ip9osmCKE15fDS2zXKT3mIj/itnj3o
DFRwkmiKYJwwi9cl7F2svzYnqp00mAMaVJ3UrzYFZhPylzWQfIJCgu47PMfGsJAx
kPvY+IA3WEk0sMTVRNSWj61QNax4G/oM8d4ipnRpt3k0UzWg1XNTZkRIAg40j8A=
=SW7Q
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, vhost, pc fixes for 2.4
The only notable thing here is vhost-user multiqueue
revert. We'll work on making it stable in 2.5,
reverting now means we won't have to maintain
bug for bug compability forever.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Mon Jul 20 12:24:00 2015 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
* remotes/mst/tags/for_upstream:
virtio-net: remove virtio queues if the guest doesn't support multiqueue
virtio-net: Flush incoming queues when DRIVER_OK is being set
pci_add_capability: remove duplicate comments
virtio-net: unbreak any layout
Revert "vhost-user: add multi queue support"
ich9: fix skipped vmstate_memhp_state subsection
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit d3462e3 broke qcow2's encryption functionality by using encrypt
instead of decrypt in the wrapper function it introduces. This was found
by qemu-iotests case 134.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
commit da51a335 adds all queues in .realize(). But if the
guest doesn't support multiqueue, we forget to remove them. And
we cannot handle the ctrl vq corretly. The guest will hang.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
This patch fixes network hang after "stop" then "cont", while network
packets keep arriving.
Tested both manually (tap, host pinging guest) and with Jason's qtest
series (plus his "[PATCH 2.4] socket: pass correct size in
net_socket_send()" fix).
As virtio_net_set_status is called when guest driver is setting status
byte and when vm state is changing, it is a good opportunity to flush
queued packets.
This is necessary because during vm stop the backend (e.g. tap) would
stop rx processing after .can_receive returns false, until the queue is
explicitly flushed or purged.
The other interesting condition in .can_receive, virtio_queue_ready(),
is handled by virtio_net_handle_rx() when guest kicks; the 3rd condition
is invalid queue index which doesn't need flushing.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit 032a74a1c0
("virtio-net: byteswap virtio-net header") breaks any layout by
requiring out_sg[0].iov_len >= n->guest_hdr_len. Fixing this by
copying header to temporary buffer if swap is needed, and then use
this buffer as part of out_sg.
Fixes 032a74a1c0
("virtio-net: byteswap virtio-net header")
Cc: qemu-stable@nongnu.org
Cc: clg@fr.ibm.com
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
This reverts commit 830d70db69.
The interface isn't fully backwards-compatible, which is bad.
Let's redo this properly after 2.4.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
By declaring another .subsections array for vmstate_tco_io_state made
vmstate_memhp_state not registered anymore. There must be only one
.subsections array for all subsections.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>
Reported-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVqQYUAAoJEB6aO1+FQIO2i5oP/22IEve0upRIprVvDKmBCh91
ablALBirktxvfriSmKOY+d+v5Zgo9R96rp4atVeSDerzV9O9Ms41NWR0olIGU98t
9ZMY8P4MTbGn3nBFn4mSIEFbVv3QFoaJwiah01caTJpEvK9wvlj30nuXEERHgcps
2g+ncZWH8lWf/f7J3myS6rhsYfgH4UB6HxwOaAdiZhpFn+5ygViOQnaL5KJYcTcE
QKpT8XA9jfQOQlegmHNqowmFqoTrx8DxiCklR/ntRFe51GfKDgZpBVJV3E9Z2+oa
RfnIfrKZftjdzk0rVanhtnis5lCP5xb3gXELhDWoE4G8IQoXBQjrVc+mV2OWfGR0
s6xdtL+w9d77kAO7/M+jeA6hR2tKJyiJ9auDW6EalMDKpsjBJMvPErAGmB7WIfib
9fxG8xGUdObrxhnph4GUSErHOB6juFFITtAEeSVqo/JrhBO2+TVnYWnUE5JzRcfj
u0u2KmT9OJTLHORkBoPlWHVPPSfSRgp8LFheyNMGXjRASocJfDZQZNgAhNpoar5N
4HlSEgYvF9Ub3SRGPnE08JNdKSMO6plBNYhzIyivFuGKAGx5tMGzgrkPbsJ8ww/w
9GgFAxmVZsiwpOhPw7HTtGt0hWHFJzqW+iK8fzXIscP/TXsSnrkTV0Jd3UKpIqem
CvSiMklKIBCoKlHZhS33
=zkW+
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/amit-virtio-rng/tags/vrng-2.4' into staging
Fire timer only when required. Brings down wakeups by a big number.
# gpg: Signature made Fri Jul 17 14:41:40 2015 BST using RSA key ID 854083B6
# gpg: Good signature from "Amit Shah <amit@amitshah.net>"
# gpg: aka "Amit Shah <amit@kernel.org>"
# gpg: aka "Amit Shah <amitshah@gmx.net>"
* remotes/amit-virtio-rng/tags/vrng-2.4:
virtio-rng: trigger timer only when guest requests for entropy
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch triggers timer only when guest requests for
entropy. As soon as first request from guest for entropy
comes we set the timer. Timer bumps up the quota value
when it gets triggered.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Message-Id: <1436962608-9961-2-git-send-email-pagupta@redhat.com>
[Re-worded patch subject, removed extra whitespace -- Amit]
Signed-off-by: Amit Shah <amit.shah@redhat.com>
This reverts commit 4e8cfbe114.
We should not poll via timer, and with ccid being fixed
to properly notify us about pending transfers we don't have to.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Coverity thinks the fallthroughs are smelly. They are correct, but
everything else in this function is like "wut?".
Refer explicitly to bits 8 and 9 of hs->kbd.modifiers instead of
shifting right first and using (1 << 7). Document what the scancode
is when hid_code is 0xe0. And add plenty of comments.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
