Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20180116134217.8725-5-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The OrderedDict class appeared in the 'collections' module
from python 2.7 onwards, so use that in preference to our
local backport if available.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20180116134217.8725-4-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The iteritems()/itervalues() methods are gone in py3, but the
items()/values() methods are still around. The latter are less
efficient than the former in py2, but this has unmeasurably
small impact on QEMU build time, so taking portability over
efficiency is a net win.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20180116134217.8725-3-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Python 3 no longer supports the bare "print" statement, it must be
called as a normal function with round brackets. It is possible to
opt-in to this new syntax with Python 2.6 onwards by importing the
"print_function" from the "__future__" module, making it easy to
support Python 2 and 3 in parallel.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20180116134217.8725-2-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
long standing bug (read "specification violation") where the server
would send an invalid response when the client has cancelled an
in-flight request. This was causing annoying spurious EINTR returns
in linux. The fix comes with some related testing in QTEST.
Other patches are code cleanup and improvements.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEtIKLr5QxQM7yo0kQcdTV5YIvc9YFAlp0OmMACgkQcdTV5YIv
c9bM2w/+ORsH7ifYVoPZDwPdhLAVg8t4aU7ak7kWSOeuTZhE8WA6GL8T4rjnhZZ4
PbFZTye0fOsZZaT30sHUIwI/CGewvdx0kMJuX339XfwaWvsrF/8tHFA8QdreclVf
YlLJwD2yZRujWPCU8k5D3hUfH2YD/w68b9Hv7K2hgsPw1Zoq7pLi/B2/BK/62G1d
35nFG97xDmcScSybrIeLwaCIKW/wgjHsWgUgAVMpgaSwtu/JTtEG5JYCZLGO6HVa
p67zdVQbCKQcdPLLllcrnGdWlA4CGxCBe+WMQyL3eJ2VDEH6XTBX8DiLstIVlXfj
vXb7vjlsYxE6rdeiMXRZWDGK+jZIePmDsI6ILlpyL0rEphuBnjEMljCxyBnOp7gS
dMTFmhfP4mApaYxeENlpQ5noDeQ/Jr1c9YeeBh9UnZ7r16/m3f2/sEIh+6QTL7YD
iR7ZG5LF0eP5SJKoZNV0i4123A5I7v1ekn5N5q6Kf4PMcY11507lxZksPhckdPgp
FPhsJJ1JQzWMcfE1mKeiZXq5Cys4EUhUK6UrOFp6tO38H/3YMuYMAz25D46Xk3Zx
qGuptCaov9uPi+5uqKuG3aJ9nMIMW9ZJdMSWo2+kb4EX4hMiOewjOJtaKA11QeS+
YoEr3szKtVnPUKsiqm+lhHL6ec5B8NQB7f8Hl88pkoLBGQzMaWU=
=9T0i
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging
This series is mostly about 9p request cancellation. It fixes a
long standing bug (read "specification violation") where the server
would send an invalid response when the client has cancelled an
in-flight request. This was causing annoying spurious EINTR returns
in linux. The fix comes with some related testing in QTEST.
Other patches are code cleanup and improvements.
# gpg: Signature made Fri 02 Feb 2018 10:16:03 GMT
# gpg: using RSA key 71D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>"
# gpg: aka "Gregory Kurz <gregory.kurz@free.fr>"
# gpg: aka "[jpeg image of size 3330]"
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6
* remotes/gkurz/tags/for-upstream:
tests/virtio-9p: explicitly handle potential integer overflows
tests: virtio-9p: add FLUSH operation test
libqos/virtio: return length written into used descriptor
tests: virtio-9p: add WRITE operation test
tests: virtio-9p: add LOPEN operation test
tests: virtio-9p: use the synth backend
tests: virtio-9p: wait for completion in the test code
tests: virtio-9p: move request tag to the test functions
9pfs: Correctly handle cancelled requests
9pfs: drop v9fs_register_transport()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
add me as the IPMI maintainer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJac2AnAAoJEGHzjJCRm/+B6iQP/1fqOS8QBJ8YB7simoHf8Vz0
3Bfnphgr/T0U9Eqb7vJye3Aug3QpaBgxCynLLhLzG3tj9s4iCYFCqHehB/e9UoFV
ok1WU6REul/8pnUjMFif23YVqn3MvZcIqva0O9/eAatUbXfRKIp7r0WRCIbLc8CW
oGSzHsPKhJQ4pCl+Cbu+xOOAx3snOF6e92SAEKTRPeivYgXDyib+L4m00YyAuCa0
qOT9/WqgRQqRfqrMZ9fI9RD9cM4xVD5bcn/COmk/KB7v1T0/on2LtI/pp4KYIS2E
lcyCs1Hhoz2nz/Y0fdi83rhScJmomiLdLv0Su08Tr3u6WcOHnIqAzS5qqKRi7WaJ
JAXp/+VX4LwEBEntAUS5PBAuM4E9DzGsQp3xypsfQHgAD9dnGJC06VPC3iRjrIim
jtVrSftzEb/dq4iK5Kp+HmFpCUIJWgjJorTdkiQ8Nd1Ld/a2efjGyeE4H7eYwCrr
uNqO8k739vR059oBdGEY/2bKeNr9imNdFRKd9CsMHX4rxM048S8NwemmmsZFWiiR
Ik6POUTXFhQytBma2ZiArKUAS4VickLgDLIW2KV95y3z3eNyr+48patBUUQdqK36
TeWE+SdwW7Nu1yD7EJzl6o1iduSUl+d2MZ62RssG4javI3hsMnWiEgaqt1fMy9V2
cSOBe7c+LmIHcu1G7lY6
=xjBI
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cminyard/tags/for-release-20180201' into staging
Lots of litte miscellaneous fixes for the IPMI code, plus
add me as the IPMI maintainer.
# gpg: Signature made Thu 01 Feb 2018 18:44:55 GMT
# gpg: using RSA key 61F38C90919BFF81
# gpg: Good signature from "Corey Minyard <cminyard@mvista.com>"
# gpg: aka "Corey Minyard <minyard@acm.org>"
# gpg: aka "Corey Minyard <corey@minyard.net>"
# gpg: aka "Corey Minyard <minyard@mvista.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FD0D 5CE6 7CE0 F59A 6688 2686 61F3 8C90 919B FF81
* remotes/cminyard/tags/for-release-20180201:
ipmi: Allow BMC device properties to be set
ipmi: disable IRQ and ATN on an external disconnect
ipmi: Fix macro issues
ipmi: Add the platform event message command
ipmi: Don't set the timestamp on add events that don't have it
ipmi: Fix SEL get/set time commands
Add maintainer for the IPMI code
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The idea is to send a victim request that will possibly block in the
server and to send a flush request to cancel the victim request.
This patch adds two test to verifiy that:
- the server does not reply to a victim request that was actually
cancelled
- the server replies to the flush request after replying to the
victim request if it could not cancel it
9p request cancellation reference:
http://man.cat-v.org/plan_9/5/flush
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
(groug, change the test to only write a single byte to avoid
any alignment or endianess consideration)
When a 9p request is flushed (ie, cancelled) by the guest, the device
is expected to simply mark the request as used, without sending a 9p
reply (ie, without writing anything into the used buffer).
To be able to test this, we need access to the length written by the
device into the used descriptor. This patch adds a uint32_t * argument
to qvirtqueue_get_buf() and qvirtio_wait_used_elem() for this purpose.
All existing users are updated accordingly.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
virtio-gpu has special code path that bypassed vIOMMU protection. So
for now let's disable iommu_platform for the device until we fully
support that (if needed).
After the patch, both virtio-vga and virtio-gpu won't allow to boot with
iommu_platform parameter set.
CC: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-id: 20180131040401.3550-1-peterx@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Changes all the occurrances of dolog() to qemu_log_mask().
Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
Message-id: 20180201172744.7504-1-programmingkidx@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
while here use TYPE_WM8750 and declare a data_req_cb() typedef.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20170919123053.32675-1-f4bug@amsat.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In this previous commit:
commit 8f61f1c5a6
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Dec 18 19:12:20 2017 +0000
ui: track how much decoded data we consumed when doing SASL encoding
I attempted to fix a flaw with tracking how much data had actually been
processed when encoding with SASL. With that flaw, the VNC server could
mistakenly discard queued data that had not been sent.
The fix was not quite right though, because it merely decremented the
vs->output.offset value. This is effectively discarding data from the
end of the pending output buffer. We actually need to discard data from
the start of the pending output buffer. We also want to free memory that
is no longer required. The correct way to handle this is to use the
buffer_advance() helper method instead of directly manipulating the
offset value.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-id: 20180201155841.27509-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The VNC server already has the ability to listen on multiple sockets.
Converting it to use the QIONetListener APIs though, will reduce the
amount of code in the VNC server and improve the clarity of what is
left.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180201164514.10330-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The previous commit:
commit 2ec78706d1
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Jan 17 16:47:15 2018 +0000
ui: convert GTK and SDL1 frontends to keycodemapdb
changed the x_keymap.c keymap so that its target was qcodes instead of
qnums. It updated the GTK frontend to take account of this change, but
forgot to update the SDL1 frontend. Thus the SDL frontend was getting
qcodes but dispatching them as if they were qnums. IOW, keyboard input
was completely hosed with SDL1. Since the keyboard layout tables are
still all based on qnums, it is easier to just keep SDL1 using qnums as
it will be deleted in a few releases time.
Reported-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: 20180201180033.14255-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Trivial test of a successful write.
Signed-off-by: Greg Kurz <groug@kaod.org>
(groug, handle potential overflow when computing request size,
add missing g_free(buf),
backend handles one written byte at a time to validate
the server doesn't do short-reads)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
The purpose of virtio-9p-test is to test the virtio-9p device, especially
the 9p server state machine. We don't really care what fsdev backend we're
using. Moreover, if we want to be able to test the flush request or a
device reset with in-flights I/O, it is close to impossible to achieve
with a physical backend because we cannot ask it reliably to put an I/O
on hold at a specific point in time.
Fortunately, we can do that with the synthetic backend, which allows to
register callbacks on read/write accesses to a specific file. This will
be used by a later patch to test the 9P flush request.
The walk request test is converted to using the synth backend.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
In order to test request cancellation, we will need to send multiple
requests and wait for the associated replies. Since we poll the ISR
to know if a request completed, we may have several replies to parse
when we detect ISR was set to 1.
This patch moves the waiting out of the reply parsing path, up into
the functional tests.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
It doesn't really makes sense to hide the request tag from the test
functions. It prevents to test the 9p server behavior when passed
a wrong tag (ie, still in use or different from P9_NOTAG for a
version request). Also the spec says that a tag is reusable as soon
as the corresponding request was replied or flushed: no need to
always increment tags like we do now. And finaly, an upcoming test
of the flush command will need to manipulate tags explicitely.
This simply changes all request functions to have a tag argument.
Except for the version request which needs P9_NOTAG, all other
tests can pass 0 since they wait for the reply before sending
another request.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
# Background
I was investigating spurious non-deterministic EINTR returns from
various 9p file system operations in a Linux guest served from the
qemu 9p server.
## EINTR, ERESTARTSYS and the linux kernel
When a signal arrives that the Linux kernel needs to deliver to user-space
while a given thread is blocked (in the 9p case waiting for a reply to its
request in 9p_client_rpc -> wait_event_interruptible), it asks whatever
driver is currently running to abort its current operation (in the 9p case
causing the submission of a TFLUSH message) and return to user space.
In these situations, the error message reported is generally ERESTARTSYS.
If the userspace processes specified SA_RESTART, this means that the
system call will get restarted upon completion of the signal handler
delivery (assuming the signal handler doesn't modify the process state
in complicated ways not relevant here). If SA_RESTART is not specified,
ERESTARTSYS gets translated to EINTR and user space is expected to handle
the restart itself.
## The 9p TFLUSH command
The 9p TFLUSH commands requests that the server abort an ongoing operation.
The man page [1] specifies:
```
If it recognizes oldtag as the tag of a pending transaction, it should
abort any pending response and discard that tag.
[...]
When the client sends a Tflush, it must wait to receive the corresponding
Rflush before reusing oldtag for subsequent messages. If a response to the
flushed request is received before the Rflush, the client must honor the
response as if it had not been flushed, since the completed request may
signify a state change in the server
```
In particular, this means that the server must not send a reply with the
orignal tag in response to the cancellation request, because the client is
obligated to interpret such a reply as a coincidental reply to the original
request.
# The bug
When qemu receives a TFlush request, it sets the `cancelled` flag on the
relevant pdu. This flag is periodically checked, e.g. in
`v9fs_co_name_to_path`, and if set, the operation is aborted and the error
is set to EINTR. However, the server then violates the spec, by returning
to the client an Rerror response, rather than discarding the message
entirely. As a result, the client is required to assume that said Rerror
response is a result of the original request, not a result of the
cancellation and thus passes the EINTR error back to user space.
This is not the worst thing it could do, however as discussed above, the
correct error code would have been ERESTARTSYS, such that user space
programs with SA_RESTART set get correctly restarted upon completion of
the signal handler.
Instead, such programs get spurious EINTR results that they were not
expecting to handle.
It should be noted that there are plenty of user space programs that do not
set SA_RESTART and do not correctly handle EINTR either. However, that is
then a userspace bug. It should also be noted that this bug has been
mitigated by a recent commit to the Linux kernel [2], which essentially
prevents the kernel from sending Tflush requests unless the process is about
to die (in which case the process likely doesn't care about the response).
Nevertheless, for older kernels and to comply with the spec, I believe this
change is beneficial.
# Implementation
The fix is fairly simple, just skipping notification of a reply if
the pdu was previously cancelled. We do however, also notify the transport
layer that we're doing this, so it can clean up any resources it may be
holding. I also added a new trace event to distinguish
operations that caused an error reply from those that were cancelled.
One complication is that we only omit sending the message on EINTR errors in
order to avoid confusing the rest of the code (which may assume that a
client knows about a fid if it sucessfully passed it off to pud_complete
without checking for cancellation status). This does mean that if the server
acts upon the cancellation flag, it always needs to set err to EINTR. I
believe this is true of the current code.
[1] https://9fans.github.io/plan9port/man/man9/flush.html
[2] https://github.com/torvalds/linux/commit/9523feac272ccad2ad8186ba4fcc891
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
[groug, send a zero-sized reply instead of detaching the buffer]
Signed-off-by: Greg Kurz <groug@kaod.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
No good reasons to do this outside of v9fs_device_realize_common().
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On some architectures, qemu doesn't support vmcoreinfo device,
and dump-guest-memory fails:
(gdb) dump-guest-memory /tmp/vmcore ppc64-le
guest RAM blocks:
target_start target_end host_addr message count
---------------- ---------------- ---------------- ------- -----
0000000000000000 0000000200000000 00003ffd86980000 added 1
0000200080000000 0000200080800000 00003ffd86170000 added 2
Python Exception <class 'gdb.error'> No symbol "vmcoreinfo_realize" in current context.:
Error occurred in Python command: No symbol "vmcoreinfo_realize" in current context.
Check that vmcoreinfo_realize symbol exists before evaluating an
expression with it.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
200 currently fails on tmpfs because it sets cache=none. However,
without that (and aio=native), the test still works now and it fails
before Jeff's series (on fc7dbc119e). So
we can probably remove the aio=native safely, and replace cache=none by
cache=$CACHEMODE.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180117135015.15051-1-mreitz@redhat.com
Signed-off-by: Jeff Cody <jcody@redhat.com>
This patch prevents a possible segmentation fault when .desc members are checked
against NULL.
The ssh_runtime_opts was added by commit
8a6a80896d ("block/ssh: Use QemuOpts for runtime
options").
This fix was inspired by
http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00883.html.
Fixes: 8a6a80896d ("block/ssh: Use QemuOpts for runtime options")
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.vnet.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
We masked the wrong bits, which prevented some of the
32-bit R registers. E.g. "fcnvxf,sgl,sgl fr22R,fr6R".
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Now that we have the prerequisites in target/hppa/,
implement the hardware for a PA7100LC.
This also enables build for hppa-softmmu.
Signed-off-by: Helge Deller <deller@gmx.de>
[rth: Since it is all new code, squashed all branch development
withing hw/hppa/ to a single patch.]
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This is an extension to the base ISA, but we can use this in
the kernel idle loop to reduce the host cpu time consumed.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
HP-UX 10.20 CD contains "add r0, r0, r27" in a delay slot,
which uses at least 5 temps.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Unknown why this works, but if we return EXCP_ITLB_MISS we
will triple-fault the first userland instruction fetch.
Is it something to do with having a combined I/DTLB?
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Linux sets sr4-sr7 all to the same value, which means that we
need not do any runtime computation to find out what space to
use in forming the GVA.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Real hardware would use an external device to control the power.
But for the moment let's invent instructions in reserved space,
to be used by our custom firmware.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Otherwise there's no way to clear them without an external command,
and it could lock the OS in the VM if they were stuck.
Signed-off-by: Corey Minyard <cminyard@mvista.com>