These are -bt, -serial, -virtcon, -parallel, -debugcon, -usbdevice.
Improves messages emitted via proper error reporting interfaces. For
instance:
$ qemu-system-x86_64 -nodefaults -S -usb -usbdevice net:vlan=xxx
qemu-system-x86_64: Parameter 'vlan' expects a number
becomes:
qemu-system-x86_64: -usbdevice net:vlan=xxx: Parameter 'vlan' expects a number
Many more remain unimproved, because they're fprintf()ed. The next
few commits will take care of that.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Cleaned up silently in commit aad04cd0, but that just got reverted.
Re-apply this part.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fixed silently in commit aad04cd0, but that just got reverted.
Re-apply the fixes, plus one missed instance: parport on Linux.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The commit's purpose is laudable:
The only way for chardev drivers to communicate an error was to
return a NULL pointer, which resulted in an error message that
said _that_ something went wrong, but not _why_.
It attempts to achieve it by changing the interface to return 0/-errno
and update qemu_chr_open_opts() to use strerror() to display a more
helpful error message. Unfortunately, it has serious flaws:
1. Backends "socket" and "udp" return bogus error codes, because
qemu_chr_open_socket() and qemu_chr_open_udp() assume that
unix_listen_opts(), unix_connect_opts(), inet_listen_opts(),
inet_connect_opts() and inet_dgram_opts() fail with errno set
appropriately. That assumption is wrong, and the commit turns
unspecific error messages into misleading error messages. For
instance:
$ qemu-system-x86_64 -nodefaults -vnc :0 -chardev socket,id=bar,host=xxx
inet_connect: host and/or port not specified
chardev: opening backend "socket" failed: No such file or directory
ENOENT is what happens to be in my errno when the backend returns
-errno. Let's put ERANGE there just for giggles:
$ qemu-system-x86_64 -nodefaults -vnc :0 -chardev socket,id=bar,host=xxx -drive if=none,iops=99999999999999999999
inet_connect: host and/or port not specified
chardev: opening backend "socket" failed: Numerical result out of range
Worse: when errno happens to be zero, return -errno erroneously
signals success, and qemu_chr_new_from_opts() dies dereferencing
uninitialized chr. I observe this with "-serial unix:".
2. All qemu_chr_open_opts() knows about the error is an errno error
code. That's simply not enough for a decent message. For instance,
when inet_dgram() can't resolve the parameter host, which errno code
should it use? What if it can't resolve parameter localaddr?
Clue: many backends already report errors in their open methods.
Let's revert the flawed commit along with its dependencies, and fix up
the silent error paths instead.
This reverts commit 6e1db57b2a.
Conflicts:
console.c
hw/baum.c
qemu-char.c
This reverts commit aad04cd024.
The parts of commit db418a0a "Add stdio char device on windows" that
depend on the reverted change fixed up.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The conditions for detecting no free target or LUN were wrong.
The LUN loop was followed by an "if" condition that is never
true, because the loop is exited as soon as lun becomes equal
to bus->info->max_lun, and never becomes greater than it.
The target loop had a wrong condition (<= instead of <). Once
this is fixed, the loop would fail in the same way as the LUN
loop.
The fix is to see whether scsi_device_find returned the device with the
last (channel, target, LUN) pair, and fail if so.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
By removing memset altogether (Patch from Stefan Hajnoczi, tested
compile only by me).
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Implement guest-shutdown RPC for Windows. Functionally this should be
equivalent to the posix implementation.
Original patch by Gal Hammer <ghammer@redhat.com>
This allows qemu-ga to function as a Windows service:
- to install the service (will auto-start on boot):
qemu-ga --service install
- to start the service:
net start qemu-ga
- to stop the service:
net stop qemu-ga
- to uninstall service:
qemu-ga --service uninstall
Original patch by Gal Hammer <ghammer@redhat.com>
This adds a win32 channel implementation that makes qemu-ga functional
on Windows using virtio-serial (unix-listen/isa-serial not currently
implemented). Unlike with the posix implementation, we do not use
GIOChannel for the following reasons:
- glib calls stat() on an fd to check whether S_IFCHR is set, which is
the case for virtio-serial on win32. Because of that, a one-time
check to determine whether the channel is readable is done by making
a call to PeekConsoleInput(), which reports the underlying handle is
not a valid console handle, and thus we can never read from the
channel.
- if one goes as far as to "trick" glib into thinking it is a normal
file descripter, the buffering is done in such a way that data
written to the output stream will subsequently result in that same
data being read back as if it were input, causing an error loop.
furthermore, a forced flush of the channel only moves the data into a
secondary buffer managed by glib, so there's no way to prevent output
from getting read back as input.
The implementation here ties into the glib main loop by implementing a
custom GSource that continually submits asynchronous/overlapped I/O to
fill an GAChannel-managed read buffer, and tells glib to poll the
corresponding event handle for a completion whenever there is no
data/RPC in the read buffer to notify the main application about.
Various stubs and #ifdefs to compile for Windows using mingw
cross-build. Still has 1 linker error due to a dependency on the
forthcoming win32 versions of the GAChannel/transport class.
Many of the current RPC implementations are very much POSIX-specific
and require complete re-writes for Windows. There are however a small
set of core guest agent commands that are common to both, and other
commands such as guest-file-* which *may* be portable. So we introduce
commands.c for the latter, and will rename guest-agent-commands.c to
commands-posix.c in a future commit. Windows implementations will go in
commands-win32.c, eventually.
This is mostly in preparation for the win32 port, which won't use
GIO channels for reasons that will be made clearer later. Here the
GAChannel class is just a loose wrapper around GIOChannel
calls/callbacks, but we also roll in the logic/configuration for
various channel types and managing unix socket connections, which makes
the abstraction much more complete and further aids in the win32 port
since isa-serial/unix-listen will not be supported initially.
There's also a bit of refactoring in the main logic to consolidate the
exit paths so we can do common cleanup for things like pid files, which
weren't always cleaned up previously.
Since we might want to test arbitrary qemu, qemu-img and
qemu-io paths, allow users to specify environment variable
values for QEMU_PROG, QEMU_IMG_PROG and QEMU_IO_PROG so
the testsuite will use those values rather than find them
on PATH. Obviously, if such env variables are not set
prior to script execution, normal detection mechanism
takes place.
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Print the paths of the programs under test
(qemu, qemu-img and qemu-io).
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test loading internal snapshots where the L1 table of the snapshot
is smaller than the current L1 table.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Until recently, qemu-img create displayed cluster_size=0 for the default
cluster size. It is changed to display the real cluster size now, which results
in the cluster size not being filtered out any more.
If the cluster size is specified explicitly in CLUSTER_SIZE, keep the output,
and if using the default, filter it out. This mostly restores the old behaviour
of the test cases; test 015 must be fixed to use CLUSTER_SIZE instead of using
extra_img_options for it.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
QED now supports the truncate (aka resize) operation for growing images.
Update test 025 so it runs for QED.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
rbd implements bdrv_truncate, so test 025 will work.
Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
016 writes past EOF which isn't support by most protocols, so limit
it to file and sheepdog, which explicitly support it.
Pointed out by Josh Durgin <josh.durgin@dreamhost.com>.
Signed-off-by: Christoph Hellwig <hch@lst.de>
The io_pattern style functions have the following loop:
for i in `seq 1 $count`; do
echo ... $(( start + i * step )) ...
done
Offsets are 1-based so start=1024, step=512, count=4 yields:
1536, 2048, 2560, 3072
Normally we expect:
1024, 1536, 2048, 2560
Most tests ignore this detail, which means that they perform I/O to a
slightly different range than expected by the test author.
Later on things got less innocent and tests started trying to compensate
for the 1-based indexing. This included negative start values in test
024 and my own attempt with count-1 in test 028!
The end result is that tests that use io_pattern are hard to reason
about and don't work the way you'd expect. It's time to clean this mess
up.
This patch switches io_pattern to 0-based offsets. This requires
adjusting the golden outputs since I/O ranges are now shifted and output
differs.
Verifying these output diffs is easy, however. Each diff hunk moves one
I/O from beyond the end of the pattern range to the beginning.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch introduces tests for protocols other than file, and
initially supports rbd and sheepdog.
Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test 019 can be run with qcow2 and qed image formats. Replace the
specific image format value with "IMGFMT" so the golden output does not
hardcode qcow2 or qed.
This patch also includes a typo fix for "occurrences".
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Increase the width of the column used for the machine name in
the "-M ?" output from 10 to 20 spaces. This fixes the formatting
so it looks nice for architectures where a few of the machines
have overly long names. (Our current longest machine name is
"petalogix-s3adsp1800" with "realview-eb-mpcore" not far behind.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The standard include files are already included in qemu-common.h.
malloc.h and alloca.h were needed for alloca() which was removed
from TCG code some years ago when switching from dyngen to TCG
(see commit 49516bc0d6).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
In the old implementation, if the new value of the property links
to the same object, as the old value, that object is first unref-ed,
and then ref-ed. This leads to unintended deinitialization of that object.
In the new implementation, this is fixed.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Barabash <alexander_barabash@mentor.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should have no visible effect, but it should just clean up the
config file a bit.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Version 1 of this patch was:
Message-Id: <1307041990-26194-11-git-send-email-ehabkost@redhat.com
http://marc.info/?l=qemu-devel&m=130704415919346
This version doesn't have the duplicate feature bits on extfeature_edx, though,
as they are being removed from the Intel models (as they are reserved bits on
Intel CPUs).
Version 1 patch description:
This patch adds Westmere as a qemu cpu model. The only
additional guest visible feature of a Westmere relative
to Nehalem is the inclusion of AES instructions. However
as other non-ABI visible modifications exist along with
fabrication changes, the CPUID data of the corresponding
deployed silicon was altered slightly to reflect this.
We've seen isolated cases where apparently unrelated yet
slightly incoherent CPUID data has caused problems, most
notably during guest boot. Providing Westmere as a
model separate fro Nehalem allows us to more easily address
such quirks.
[ehabkost: edited commit message to have a better Subject line]
Signed-off-by: john cooper <john.cooper@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Changes version 1 -> version 2:
- Remove the duplicate feature bits on extfeature_edx, that are
reserved on Intel CPUs
- Reorder feature flags
- Remove x2apic from the definition because x2apic requires some fixes
that have to be resubmitted
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch removes the replicated feature flags from cpuid 8000_0001:edx
(extfeature_edx) from Intel models, as the duplicated feature flags are present
only on AMD CPUs. On Intel models, only the i64, syscall, and xd flags are kept
on extfeature_edx.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Original John's patch description was:
cpu model bug fixes and definition corrections
This patch was intended to address the replicated feature
flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
This is due to AMD's definition where these flags are
mostly cloned in the 8000_0001:edx cpuid function.
qemu64 attempted to glue together the respective Intel
and AMD nearly disjoint features and this propagated to
the new Intel models as doing so was believed conservative
at the time. However after further soak and test lugging
around this cruft doesn't provide any value, could
conceivably confuse a guest, and has confused users trying
to maintain/add cpu definitions. This also caused issues
for libvirt attempting to track this mis-encoding.
So we've here tossed out the AMD replicated definitions
from the Intel models, added a few replications into AMD
definitions which were missing according to AMD's latest
CPUID document, and reordered the config file flags to
follow intuitive sequential bit ordering. Also two flag
name aliases were added for clarity to Intel models. The
end result being the models definitions now conform to
their respective cpuid specifications sans x2apic which is
emulated by kvm.
This was tested with the following combinations:
[Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
[Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host
Yielding successful boots in all cases.
Signed-off-by: john cooper <john.cooper@redhat.com>
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch adds some missing flags to extfeature_edx, that were missing
according to AMD's latest CPUID document.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Original John's patch description was:
cpu model bug fixes and definition corrections
This patch was intended to address the replicated feature
flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
This is due to AMD's definition where these flags are
mostly cloned in the 8000_0001:edx cpuid function.
qemu64 attempted to glue together the respective Intel
and AMD nearly disjoint features and this propagated to
the new Intel models as doing so was believed conservative
at the time. However after further soak and test lugging
around this cruft doesn't provide any value, could
conceivably confuse a guest, and has confused users trying
to maintain/add cpu definitions. This also caused issues
for libvirt attempting to track this mis-encoding.
So we've here tossed out the AMD replicated definitions
from the Intel models, added a few replications into AMD
definitions which were missing according to AMD's latest
CPUID document, and reordered the config file flags to
follow intuitive sequential bit ordering. Also two flag
name aliases were added for clarity to Intel models. The
end result being the models definitions now conform to
their respective cpuid specifications sans x2apic which is
emulated by kvm.
This was tested with the following combinations:
[Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
[Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host
Yielding successful boots in all cases.
Signed-off-by: john cooper <john.cooper@redhat.com>
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Use 'i64' instead of 'lm' and 'xd' instead of 'nx' on Intel models.
The flags have different names on Intel docs, so use those names for clarity.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Changes v1 -> v2:
- Rebase patch against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
pclmulqdq: /proc/cpuinfo on Linux and all documentation I have seen uses
pclmulqdq as the flag name. As the only document using pclmuldq seems to
be the Intel CPUID documentation (Application Note 485), it looks like a
typo and not the correct name for the flag.
ffxsr: AMD docs refer to fxsr_opt as ffxsr, so allow this named to be
used too.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This will make it easier to review and change the flag list in the future.
No behaviour change should be introduced by this, as it is just changing
the flag order on the config file.
To make sure the flag sets are really not changed by this patch, I have
used the following stupid script to compare the flag values in the
config files:
https://gist.github.com/1004885
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This has been the de facto situation for a while now.
Add a tree, too.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It's emitted whenever the tray is moved by the guest or by HMP/QMP
commands.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Kevin Wolf <kwolf@redhat.com>
This is used to sync the physical tray state after migration when
using CD-ROM passthrough. However, migrating when using passthrough
is broken anyway and shouldn't be supported...
So, drop this function as it causes a problem with the DEVICE_TRAY_MOVED
event, which is going to be introduced by the next commit.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Kevin Wolf <kwolf@redhat.com>
It's not needed. Besides we can then assume that bdrv_eject() is
only called when there's a tray state change, which is useful to
the DEVICE_TRAY_MOVED event (going to be added in a future
commit).
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Kevin Wolf <kwolf@redhat.com>
Markus Armbruster