John Snow [Wed, 6 Jun 2018 23:02:57 +0000 (19:02 -0400)]
jobs: fix verb references in docs
These point to the job versions now, not the blockjob versions which
don't really exist anymore.
Except set-speed, which does. It sticks out like a sore thumb. This
patch doesn't fix that, but it doesn't make it any worse, either.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
John Snow [Wed, 6 Jun 2018 23:02:56 +0000 (19:02 -0400)]
jobs: fix stale wording
During the design for manual completion, we decided not to use the
"manual" property as a shorthand for both auto-dismiss and auto-finalize.
Fix the wording.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Eric Blake [Mon, 11 Jun 2018 21:39:27 +0000 (16:39 -0500)]
iotests: Add test 221 to catch qemu-img map regression
Although qemu-img creates aligned files (by rounding up), it
must also gracefully handle files that are not sector-aligned.
Test that the bug fixed in the previous patch does not recur.
It's a bit annoying that we can see the (implicit) hole past
the end of the file on to the next sector boundary, so if we
ever reach the point where we report a byte-accurate size rather
than our current behavior of always rounding up, this test will
probably need a slight modification.
Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Eric Blake [Mon, 11 Jun 2018 21:39:26 +0000 (16:39 -0500)]
qemu-img: Fix assert when mapping unaligned raw file
Commit a290f085 exposed a latent bug in qemu-img map introduced
during the conversion of block status to be byte-based. Earlier in
commit 5e344dd8, the internal interface get_block_status() switched
to take byte-based parameters, but still called a sector-based
block layer function; as such, rounding was added in the lone
caller to obey the contract. However, commit 237d78f8 changed
get_block_status() to truly be byte-based, at which point rounding
to sector boundaries can result in calling bdrv_block_status() with
'bytes == 0' (a coding error) when the boundary between data and a
hole falls mid-sector (true for the past-EOF implicit hole present
in POSIX files). Fix things by removing the rounding that is now
no longer necessary.
Peter Maydell [Fri, 15 Jun 2018 10:41:44 +0000 (11:41 +0100)]
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging
# gpg: Signature made Fri 15 Jun 2018 03:47:09 BST
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@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: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* remotes/jasowang/tags/net-pull-request:
vhost-user: delete net client if necessary
e1000e: Do not auto-clear ICR bits which aren't set in EIAC
net: Fix a potential segfault
tap: set vhostfd passed from qemu cli to non-blocking
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
linzhecheng [Tue, 12 Jun 2018 02:24:45 +0000 (10:24 +0800)]
vhost-user: delete net client if necessary
As qemu_new_net_client create new ncs but error happens later,
ncs will be left in global net_clients list and we can't use them any
more, so we need to cleanup them.
Cc: qemu-stable@nongnu.org Signed-off-by: linzhecheng <linzhecheng@huawei.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
Jan Kiszka [Sun, 1 Apr 2018 21:17:55 +0000 (23:17 +0200)]
e1000e: Do not auto-clear ICR bits which aren't set in EIAC
The spec does not justify clearing of any E1000_ICR_OTHER_CAUSES when
E1000_ICR_OTHER is set in EIAC. In fact, removing this code fixes the
issue the Linux driver runs into since 4aea7a5c5e94 ("e1000e: Avoid
receiver overrun interrupt bursts") and was worked around by 745d0bd3af99 ("e1000e: Remove Other from EIAC").
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
Fixes: 547203ead4327 ("net: List available netdevs with "-netdev help") Reviewed-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Lin Ma <lma@suse.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
Commit: c471ad0e9bd46 (vhost_net: device IOTLB support) took care of
setting vhostfd to non-blocking when QEMU opens /dev/host-net but if
the fd is passed from qemu cli then we need to ensure that fd is set
to non-blocking.
Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support") Cc: qemu-stable@nongnu.org Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
Peter Maydell [Thu, 14 Jun 2018 10:35:22 +0000 (11:35 +0100)]
Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2018-06-13' into staging
Miscellaneous patches for 2018-06-13
# gpg: Signature made Wed 13 Jun 2018 13:51:51 BST
# gpg: using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* remotes/armbru/tags/pull-misc-2018-06-13:
Purge uses of banned g_assert_FOO()
coverity-model: replay data is considered trusted
Revert "Makefile: add target to print generated files"
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
instead of destroying and recreating window, fixes segfault caused by
handle_keyup trying to access no more existing window when using
Ctrl-Alt-U to restore window "un-scaled" dimensions
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7f92b80 (LWP 3711)]
handle_keyup (ev=0x7fffffffd010) at ui/sdl2.c:416
416 scon->ignore_hotkeys = false;
(gdb) bt
#0 handle_keyup (ev=0x7fffffffd010) at ui/sdl2.c:416
#1 sdl2_poll_events (scon=0x100fee5a8) at ui/sdl2.c:608
#2 0x0000000100585bf2 in dpy_refresh (s=0x101ad3e00) at ui/console.c:1658
#3 gui_update (opaque=0x101ad3e00) at ui/console.c:205
#4 0x0000000100690f2c in timerlist_run_timers (timer_list=0x100ede130) at util/qemu-timer.c:536
#5 0x0000000100691177 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547
#6 qemu_clock_run_all_timers () at util/qemu-timer.c:674
#7 0x0000000100691651 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:503
#8 0x00000001003d650f in main_loop () at vl.c:1848
#9 0x0000000100289681 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4605
Eric Blake [Thu, 31 May 2018 21:24:35 +0000 (16:24 -0500)]
block: Ignore generated job QAPI files
Commit bf42508f introduced new generated files; make sure they
don't get accidentally committed from an in-tree build.
Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180531212435.165261-1-eblake@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
We banned use of certain g_assert_FOO() functions outside tests, and
made checkpatch.pl flag them (commit 6e9389563e5). We neglected to
purge existing uses. Do that now.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180608170231.27912-1-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: John Snow <jsnow@redhat.com>
The patch snuck in by accident without having been posted to
qemu-devel. It's entirely redundant: existing target print-% already
serves the purpose.
Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180504054241.6833-1-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* remotes/vivier2/tags/linux-user-for-3.0-pull-request:
linux-user/sparc64: Add inotify_rm_watch and tee syscalls
linux-user/microblaze: Fix typo in accept4 syscall
linux-user/hppa: Fix typo in mknodat syscall
linux-user/alpha: Fix epoll syscalls
qemu-binfmt-conf.sh: ignore the OS/ABI field
linux-user: disable qemu-bridge-helper and socket_scm_helper build
linux-user: Use is_error() to avoid warnings and make the code clearer
linux-user: Export use is_error(), use it to avoid warnings
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/kraxel/tags/usb-20180612-pull-request:
usb-mtp: Return error on suspicious TYPE_DATA packet from initiator
usb-hcd-xhci-test: add a test for ccid hotplug
usb-ccid: fix bus leak
object: fix OBJ_PROP_LINK_UNREF_ON_RELEASE ambivalence
bus: do not unref the added child bus on realize
usb/dev-mtp: Fix use of uninitialized values
usb: correctly handle Zero Length Packets
usb: update docs
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 12 Jun 2018 13:32:19 +0000 (14:32 +0100)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-3.0-20180612' into staging
ppc patch queue 2018-06-12
Here's another batch of ppc patches towards the 3.0 release. There's
a fair bit here, because I've been working through my mail backlog
after a holiday. There's not much of a central theme, amongst other
things we have:
* ppc440 / sam460ex improvements
* logging and error cleanups
* 40p (PReP) bugfixes
* Macintosh fixes and cleanups
* Add emulation of the new POWER9 store-forwarding barrier
instruction variant
* Hotplug cleanups
* remotes/dgibson/tags/ppc-for-3.0-20180612: (33 commits)
spapr_pci: Remove unhelpful pagesize warning
xics_kvm: use KVM helpers
ppc/pnv: fix LPC HC firmware address space
spapr: handle cpu core unplug via hotplug handler chain
spapr: handle pc-dimm unplug via hotplug handler chain
spapr: introduce machine unplug handler
spapr: move memory hotplug support check into spapr_memory_pre_plug()
spapr: move lookup of the node into spapr_memory_plug()
spapr: no need to verify the node
target/ppc: Allow PIR read in privileged mode
ppc4xx_i2c: Clean up and improve error logging
target/ppc: extend eieio for POWER9
mos6522: convert VMSTATE_TIMER_PTR_TEST to VMSTATE_TIMER_PTR
mos6522: move timer frequency initialisation to mos6522_reset
cuda: embed mos6522_cuda device directly rather than using QOM object link
mos6522: fix vmstate_mos6522_timer version in vmstate_mos6522
ppc: add missing FW_CFG_PPC_NVRAM_FLAT definition
ppc: remove obsolete macio_init() definition from mac.h
ppc: remove obsolete pci_pmac_init() definitions from mac.h
hw/misc/mos6522: Add trailing '\n' to qemu_log() calls
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bandan Das [Fri, 18 May 2018 18:49:03 +0000 (14:49 -0400)]
usb-mtp: Return error on suspicious TYPE_DATA packet from initiator
CID 1390604
If the initiator sends a packet with TYPE_DATA set without
initiating a CMD_GET_OBJECT_INFO first, then usb_mtp_get_data
can trip on a null s->data_out.
Signed-off-by: Bandan Das <bsd@redhat.com>
Message-Id: <jpgr2m8ajfk.fsf_-_@linux.bootlegged.copy> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A link property can be set during creation, with
object_property_add_link() and later with object_property_set_link().
add_link() doesn't add a reference to the target object, while
set_link() does.
Furthemore, OBJ_PROP_LINK_UNREF_ON_RELEASE flags, set during add_link,
says whether a reference must be released when the property is destroyed.
This can lead to leaks if the property was later set_link(), as the
added reference is never released.
Instead, rename OBJ_PROP_LINK_UNREF_ON_RELEASE to OBJ_PROP_LINK_STRONG
and use that has an indication on how the link handle reference
management in set_link().
hw/usb/dev-mtp.c:971:5: warning: 4th function call argument is an uninitialized value
trace_usb_mtp_op_get_partial_object(s->dev.addr, o->handle, o->path,
c->argv[1], c->argv[2]);
^~~~~~~~~~
and:
hw/usb/dev-mtp.c:981:12: warning: Assigned value is garbage or undefined
offset = c->argv[1];
^ ~~~~~~~~~~
USB Specification Revision 2.0, §5.5.3:
The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following:
• Has transferred exactly the amount of data specified during the Setup stage
• Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet"
hw/usb/redirect.c:802:9: warning: Declared variable-length array (VLA) has zero size
uint8_t buf[size];
^~~~~~~~~~~ ~~~~
Gerd Hoffmann [Tue, 5 Jun 2018 13:29:15 +0000 (15:29 +0200)]
usb: update docs
xhci is rock solid meanwhile. So move it up in the docs and feature it
as prefered usb host adapter, instead of the old shy version saying "you
might want try ...".
While being at it rework the text on ehci and companion controllers too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20180605132915.3640-1-kraxel@redhat.com
David Gibson [Thu, 19 Apr 2018 06:07:40 +0000 (16:07 +1000)]
spapr_pci: Remove unhelpful pagesize warning
By default, the IOMMU model built into the spapr virtual PCI host bridge
supports 4kiB and 64kiB IOMMU page sizes. However this can be overridden
which may be desirable to allow larger IOMMU page sizes when running a
guest with hugepage backing and passthrough devices. For that reason a
warning was printed when the device wasn't configured to allow the pagesize
with which guest RAM is backed.
Experience has proven, however, that this message is more confusing than
useful. Worse it sometimes makes little sense when the host-available page
sizes don't match those available on the guest, which can happen with
a POWER8 guest running on a POWER9 KVM host.
Long term we do want better handling to allow large IOMMU page sizes to be
used, but for now this parameter and warning don't really accomplish it.
So, remove the message, pending a better solution.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
spapr: handle cpu core unplug via hotplug handler chain
Factor out cpu core unplug into separate function from
spapr_core_release(). Then use generic hotplug_handler_unplug() to trigger
cpu core unplug, which would call spapr_machine_device_unplug() ->
spapr_core_unplug() in the end.
This way unplug operation is not buried in spapr internals and located
in the same place like in other targets, following similar
logic/call chain across targets.
Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
spapr: handle pc-dimm unplug via hotplug handler chain
Factor out memory unplug into separate function from spapr_lmb_release().
Then use generic hotplug_handler_unplug() to trigger memory unplug,
which will call spapr_machine_device_unplug() -> spapr_memory_unplug()
in the end.
This way unplug operation is not buried in lmb internals and located in
the same place like in other targets, following similar logic/call chain
across targets.
Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We'll be handling unplug of e.g. CPUs and PCDIMMs via the general
hotplug handler soon, so let's add that handler function.
Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The node property can always be queried and the value has already been
verified in pc_dimm_realize().
Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
BALATON Zoltan [Wed, 6 Jun 2018 13:31:48 +0000 (15:31 +0200)]
ppc4xx_i2c: Clean up and improve error logging
Make it more readable by converting register indexes to decimal
(avoids lot of superfluous 0x0) and distinguish errors caused by
accessing non-existent vs. unimplemented registers.
No functional change.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
POWER9 introduced a new variant of the eieio instruction using bit 6
as a hint to tell the CPU it is a store-forwarding barrier.
The usage of this eieio extension was recently added in Linux 4.17
which activated the "support for a store forwarding barrier at kernel
entry/exit".
Unfortunately, it is not possible to insert this new eieio instruction
without considerable change in ppc_tr_translate_insn(). So instead we
loosen the QEMU eieio instruction mask and modify the gen_eieio()
helper to test for bit6. On non-POWER9 CPUs, the bit6 is just ignored
but a warning is emitted as this is not an instruction software should
be using.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
mos6522: convert VMSTATE_TIMER_PTR_TEST to VMSTATE_TIMER_PTR
The timers are configured in the mos6522 init function and therefore will
always exist, so the function can never return false.
Peter also pointed out that this is the only remaining user of
VMSTATE_TIMER_PTR_TEST in the codebase, so we might as well just convert it
over to VMSTATE_TIMER_PTR and remove mos6522_timer_exist() as it is no
longer required.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
mos6522: move timer frequency initialisation to mos6522_reset
The 6522 VIA timer frequency cannot be set by altering registers within the
device itself and hence it is a fixed property of the machine.
Move the initialisation of the timer frequency to the mos6522 reset function
and ensure that any subclasses always call the parent reset function so that
it isn't required to store the timer frequency within vmstate_mos6522_timer
itself.
By moving the frequency initialisation to the device reset function then we
find that the realize function for both mos6522 and mos6522_cuda becomes
obsolete and can simply be removed.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
cuda: embed mos6522_cuda device directly rather than using QOM object link
Examining the migration stream it can be seen that the mos6522 device state is
being stored separately rather than as part of the CUDA device which is
incorrect (and likely to cause issues if another mos6522 device is added to
the machine).
Resolve this by embedding the mos6522_cuda device directly within the CUDA
device rather than using a QOM object link to reference the device separately.
Note that we also bump the version in vmstate_cuda to reflect this change: this
isn't particularly important for the moment as the Mac machine migration isn't
100% reliable due to issues migrating the timebase under TCG.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This is used in OpenBIOS to define the memory layout of the NVRAM device. Whilst
currently left at its default value, add the missing definition to ensure it is
reserved.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
ppc: remove obsolete macio_init() definition from mac.h
Commits b6712ea391 removed the macio_init() function but missed the header
prototype in mac.h. Remove it since it is no longer needed.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
ppc: remove obsolete pci_pmac_init() definitions from mac.h
Commits 7b19318bee and 8ce3f743c7 removed the pci_pmac_init() and
pci_pmac_u3_init() functions but missed the header prototypes in mac.h. Remove
them since they are no longer needed.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This allows KVM with the Book3S radix MMU mode to take advantage of
THP and install larger pages in the partition scope page tables (the
host translation).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
VIO devices have an "irq" property that can be used by the sPAPR IRQ
allocator as an IRQ number hint. But it is not set in QEMU nor in
libvirt. It brings unnecessary complexity to the underlying layers
managing the IRQ number space and it is in full opposition with the
new static IRQ allocator we want to introduce in sPAPR.
Let's deprecate it to simplify the spapr_irq_alloc routine in the
future.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
[dwg: Check qtest_enabled() to suppress bogus warnings from make check] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With this patch Qemu makes this register available as a hypervisor
privileged register.
Note that bits set in this register disable features of the processor.
Currently the only register state that is supported is when the register
is zeroed (enable all features). This is sufficient for guests to
once again boot.
Mark Cave-Ayland [Thu, 24 May 2018 05:39:58 +0000 (06:39 +0100)]
prep: fix keyboard for the 40p machine
Commit 72d3d8f052 "hw/isa/superio: Add a keyboard/mouse controller (8042)"
added an 8042 keyboard device to the PC87312 superio device to replace that
being used by the prep machine.
Unfortunately this commit didn't do the same for the 40p machine which broke
the keyboard by registering two 8042 keyboard devices at the same address.
Resolve this by similarly removing the 8042 keyboard from the 40p machine as
done for the prep machine in commit 72d3d8f052.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Mark Cave-Ayland [Fri, 25 May 2018 21:15:23 +0000 (22:15 +0100)]
40p: remove pci_allow_0_address = true from 40p machine class
The Linux sandalfoot zImage has an initialisation process which resets the
VGA controller by setting all the BAR addresses to zero to access the VGA
ioports at their legacy addresses.
Unfortunately setting the framebuffer BAR to address 0 makes the framebuffer
memory overlap the internal VGA memory causing accesses to fail, and so
prevents the kernel from switching successfully to text mode.
Since OpenHackWare configures the framebuffer BAR address outside of the legacy
VGA internal memory space, remove pci_allow_0_address from the 40p machine class
which causes the BAR reprogramming to zero to fail and so the VGA internal
memory can be accessed correctly again.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thomas Huth [Mon, 28 May 2018 18:11:19 +0000 (20:11 +0200)]
target/ppc: Use proper logging function for possible guest errors
fprintf() and qemu_log_separate() are frowned upon these days for printing
logging information in QEMU. Accessing the wrong SPRs indicates wrong guest
behaviour in most cases, and we've got a proper way to log such situations,
which is the qemu_log_mask(LOG_GUEST_ERROR, ...) function. So use this
function now for logging the bad SPR accesses instead.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
hw/ppc/spapr_drc: Replace error_setg(&error_abort) by error_report() + abort()
Use error_report() + abort() instead of error_setg(&error_abort),
as suggested by the "qapi/error.h" documentation:
Please don't error_setg(&error_fatal, ...), use error_report() and
exit(), because that's more obvious.
Likewise, don't error_setg(&error_abort, ...), use assert().
Use abort() instead of the suggested assert() because the error message
already got displayed.
Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
uninorth: remove token register from uninorth device
>From observation of various OS sources it can be seen that the token register
introduced in 4e46dcdbd3 "PPC: Newworld: Add uninorth token register" is not
required, since the only register currently implemented is the uninorth hardware
version which is read-only.
Remove the token register implementation and instead return the uninorth
version corresponding to the hardware.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Ross Zwisler [Thu, 7 Jun 2018 22:31:11 +0000 (16:31 -0600)]
nvdimm: make persistence option symbolic
Replace the "nvdimm-cap" option which took numeric arguments such as "2"
with a more user friendly "nvdimm-persistence" option which takes symbolic
arguments "cpu" or "mem-ctrl".
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Suggested-by: Michael S. Tsirkin <mst@redhat.com> Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Ross Zwisler [Thu, 7 Jun 2018 22:31:09 +0000 (16:31 -0600)]
hw/i386: Update SSDT table used by "make check"
This commit:
commit aa78a16d8645 ("hw/i386: Rename 2.13 machine types to 3.0")
updated the name used to create the q35 machine, which in turn changed the
SSDT table which is generated when we run "make check":
acpi-test: Warning! SSDT mismatch. Actual [asl:/tmp/asl-QZDWJZ.dsl,
aml:/tmp/aml-T8JYJZ], Expected [asl:/tmp/asl-DTWVJZ.dsl,
aml:tests/acpi-test-data/q35/SSDT.dimmpxm].
Here's the only difference, aside from the checksum:
< Name (MEMA, 0x07FFF000)
---
> Name (MEMA, 0x07FFE000)
Update the binary table that we compare against so it reflects this name
change.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Fixes: commit aa78a16d8645 ("hw/i386: Rename 2.13 machine types to 3.0") Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
qapi: add disabled parameter to block-dirty-bitmap-add
This is needed, for example, to create a new bitmap and merge several
disabled bitmaps into a new one. Without this flag we will have to
put block-dirty-bitmap-add and block-dirty-bitmap-disable into one
transaction.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180606182449.1607-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180606182449.1607-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Expose the ability to turn bitmaps "on" or "off". This is experimental
and principally for the sake of the Libvirt Checkpoints API, and it may
or may not be committed for 3.0.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180606182449.1607-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
block/dirty-bitmap: add lock to bdrv_enable/disable_dirty_bitmap
Add locks and remove comments about BQL accordingly to
dirty_bitmap_mutex definition in block_int.h.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180606182449.1607-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Paolo Bonzini [Mon, 11 Jun 2018 18:53:31 +0000 (14:53 -0400)]
block: simplify code around releasing bitmaps
QLIST_REMOVE does not require walking the list, and once the "bitmap"
argument is removed from bdrv_do_release_matching_dirty_bitmap_locked
the code simplifies a lot and it is worth inlining everything in the
callers of bdrv_do_release_matching_dirty_bitmap.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20180326104037.6894-1-pbonzini@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Paolo Bonzini [Mon, 11 Jun 2018 18:53:31 +0000 (14:53 -0400)]
block: remove bdrv_dirty_bitmap_make_anon
All this function is doing will be repeated by
bdrv_do_release_matching_dirty_bitmap_locked, except
resetting bm->persistent. But even that does not matter
because the bitmap will be freed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20180323164254.26487-1-pbonzini@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Igor Mammedov [Tue, 5 Jun 2018 14:00:42 +0000 (16:00 +0200)]
cli: Don't run early event loop if no --preconfig was specified
After 047f7038f586d215 it is possible for event loop to run two
times. First time whilst parsing command line options (the idea
is to bring up monitor early so that management applications can
tweak config before machine is initialized). And the second time
is after everything is set up (this is the usual place). In both
cases the event loop is called as main_loop_wait(nonblocking =
false) which causes the event loop to block until at least one
event occurred.
Now, consider that somebody (i.e. libvirt) calls us with
-daemonize. This operation is split in two steps. The main()
calls os_daemonize() which fork()-s and then waits in read()
until child notifies it via write():
Here it can be clearly seen that main() does not exit until an
event occurs, but at the same time nobody will touch the monitor
socket until their exec("qemu-system-*") finishes. So the whole
thing deadlocks.
The solution is to not call main_loop_wait() unless --preconfig was
specified (in which case caller knows they must connect to the
socket before exec() finishes).
Patch also fixes hang when -nodefaults option is used, which were
causing QEMU hang in the early main_loop_wait() indefinitely by
the same means (not calling main_loop_wait() unless --preconfig
is present on CLI)
Based on
From: Michal Privoznik <mprivozn@redhat.com>
Subject: [PATCH] cli: Don't run early event loop if no --preconfig was specified
Message-Id: <ad910973c593c5ac2fed3a10ea958f7e9c12f82c.1527935663.git.mprivozn@redhat.com> Fixes: 047f7038f586d215 Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1528207243-268226-2-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Peter Maydell [Mon, 11 Jun 2018 14:31:20 +0000 (15:31 +0100)]
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2018-06-11' into staging
Block patches:
- Various bug fixes
- Removal of qemu-img convert's deprecated -s option
- qemu-io now exits with an error when a command failed
# gpg: Signature made Mon 11 Jun 2018 15:23:42 BST
# gpg: using RSA key F407DB0061D5CF40
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>"
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2018-06-11: (29 commits)
iotests: Add case for a corrupted inactive image
qcow2: Do not mark inactive images corrupt
block: Make bdrv_is_writable() public
throttle: Fix crash on reopen
block/qcow2-bitmap: fix free_bitmap_clusters
qemu-img: Remove deprecated -s snapshot_id_or_name option
iotests: Fix 219's timing
iotests: improve pause_job
iotests: Test post-backing convert target behavior
qemu-img: Special post-backing convert handling
iotests: Add test for rebasing with relative paths
qemu-img: Resolve relative backing paths in rebase
iotests: Let 216 make use of qemu-io's exit code
iotests.py: Add qemu_io_silent
qemu-io: Exit with error when a command failed
qemu-io: Let command functions return error code
qemu-io: Drop command functions' return values
iotests: Repairing error during snapshot deletion
qcow2: Repair OFLAG_COPIED when fixing leaks
iotests: Rework 113
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Max Reitz [Wed, 6 Jun 2018 19:37:02 +0000 (21:37 +0200)]
iotests: Add case for a corrupted inactive image
Reviewed-by: John Snow <jsnow@redhat.com> Tested-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 6 Jun 2018 19:37:01 +0000 (21:37 +0200)]
qcow2: Do not mark inactive images corrupt
When signaling a corruption on a read-only image, qcow2 already makes
fatal events non-fatal (i.e., they will not result in the image being
closed, and the image header's corrupt flag will not be set). This is
necessary because we cannot set the corrupt flag on read-only images,
and it is possible because further corruption of read-only images is
impossible.
Inactive images are effectively read-only, too, so we should do the same
for them. bdrv_is_writable() can tell us whether an image can actually
be written to, so use its result instead of !bs->read_only.
(Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in
bdrv_co_pwritev() will fail, crashing qemu.)
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-3-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 6 Jun 2018 19:37:00 +0000 (21:37 +0200)]
block: Make bdrv_is_writable() public
This is a useful function for the whole block layer, so make it public.
At the same time, users outside of block.c probably do not need to make
use of the reopen functionality, so rename the current function to
bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function
that just passes NULL to it for the reopen queue.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-2-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Alberto Garcia [Fri, 8 Jun 2018 15:15:36 +0000 (18:15 +0300)]
throttle: Fix crash on reopen
The throttle block filter can be reopened, and with this it is
possible to change the throttle group that the filter belongs to.
The way the code does that is the following:
- On throttle_reopen_prepare(): create a new ThrottleGroupMember
and attach it to the new throttle group.
- On throttle_reopen_commit(): detach the old ThrottleGroupMember,
delete it and replace it with the new one.
The problem with this is that by replacing the ThrottleGroupMember the
previous value of io_limits_disabled is lost, causing an assertion
failure in throttle_co_drain_end().
This problem can be reproduced by reopening a throttle node:
Since we only want to change the throttle group on reopen there's no
need to create a ThrottleGroupMember and discard the old one. It's
easier if we simply detach it from its current group and attach it to
the new one.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Message-id: 20180608151536.7378-1-berto@igalia.com Signed-off-by: Max Reitz <mreitz@redhat.com>
This assert may fail, because bitmap_table is not initialized. Just
drop it, as it's obvious, that bitmap_table_load sets bitmap_table
parameter only when returning zero.
Reported-by: Pavel Butsykin <pbutsykin@virtuozzo.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20180608101225.2575-1-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com>
It has been marked as deprecated since QEMU v2.0 already, so it
is time now to finally remove it.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1528288551-31641-1-git-send-email-thuth@redhat.com Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 6 Jun 2018 19:06:28 +0000 (21:06 +0200)]
iotests: Fix 219's timing
219 has two issues that may lead to sporadic failure, both of which are
the result of issuing query-jobs too early after a job has been
modified. This can then lead to different results based on whether the
modification has taken effect already or not.
First, query-jobs is issued right after the job has been created.
Besides its current progress possibly being in any random state (which
has already been taken care of), its total progress too is basically
arbitrary, because the job may not yet have been able to determine it.
This patch addresses this by just filtering the total progress, like
what has been done for the current progress already. However, for more
clarity, the filtering is changed to replace the values by a string
'FILTERED' instead of deleting them.
Secondly, query-jobs is issued right after a job has been resumed. The
job may or may not yet have had the time to actually perform any I/O,
and thus its current progress may or may not have advanced. To make
sure it has indeed advanced (which is what the reference output already
assumes), keep querying it until it has.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606190628.8170-1-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
It's possible, that job was finished during waiting. In this case we
will see error message "Timeout waiting for job to pause" which is not
very informative. So, let's check during waiting iteration that the job
exists.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20180601115923.17159-1-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 1 May 2018 16:57:50 +0000 (18:57 +0200)]
iotests: Test post-backing convert target behavior
This adds a test case to 122 for what happens when you convert to a
target with a backing file that is shorter than the target, and the
image format does not support efficient zero writes (as is the case with
qcow2 v2).
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180501165750.19242-3-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 1 May 2018 16:57:49 +0000 (18:57 +0200)]
qemu-img: Special post-backing convert handling
Currently, qemu-img convert writes zeroes when it reads zeroes.
Sometimes it does not because the target is initialized to zeroes
anyway, so we do not need to overwrite (and thus potentially allocate)
it. This is never the case for targets with backing files, though. But
even they may have an area that is initialized to zeroes, and that is
the area past the end of the backing file (if that is shorter than the
overlay).
So if the target format's unallocated blocks are zero and there is a gap
between the target's backing file's end and the target's end, we do not
have to explicitly write zeroes there.
Max Reitz [Wed, 9 May 2018 18:20:02 +0000 (20:20 +0200)]
iotests: Add test for rebasing with relative paths
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509182002.8044-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 18:20:01 +0000 (20:20 +0200)]
qemu-img: Resolve relative backing paths in rebase
Currently, rebase interprets a relative path for the new backing image
as follows:
(1) Open the new backing image with the given relative path (thus relative to
qemu-img's working directory).
(2) Write it directly into the overlay's backing path field (thus
relative to the overlay).
If the overlay is not in qemu-img's working directory, both will be
different interpretations, which may either lead to an error somewhere
(either rebase fails because it cannot open the new backing image, or
your overlay becomes unusable because its backing path does not point to
a file), or, even worse, it may result in your rebase being performed
for a different backing file than what your overlay will point to after
the rebase.
Fix this by interpreting the target backing path as relative to the
overlay, like qemu-img does everywhere else.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835 Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180509182002.8044-2-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 19:43:02 +0000 (21:43 +0200)]
iotests: Let 216 make use of qemu-io's exit code
As a showcase of how you can use qemu-io's exit code to determine
success or failure (same for qemu-img), this test is changed to use
qemu_io_silent() instead of qemu_io(), and to assert the exit code
instead of logging the filtered result.
One real advantage of this is that in case of an error, you get a
backtrace that helps you locate the issue in the test file quickly.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509194302.21585-6-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 19:43:01 +0000 (21:43 +0200)]
iotests.py: Add qemu_io_silent
With qemu-io now returning a useful exit code, some tests may find it
sufficient to just query that instead of logging (and filtering) the
whole output.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509194302.21585-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 19:43:00 +0000 (21:43 +0200)]
qemu-io: Exit with error when a command failed
Currently, qemu-io basically always returns success when it gets to
interactive mode (so once the whole command line has been parsed; even
before the commands on the command line are interpreted). That is not
very useful.
This patch makes qemu-io return failure when any of the executed
commands failed.
Max Reitz [Wed, 9 May 2018 19:42:59 +0000 (21:42 +0200)]
qemu-io: Let command functions return error code
This is basically what everything else in the qemu code base does, so we
can do it here, too.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509194302.21585-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 19:42:58 +0000 (21:42 +0200)]
qemu-io: Drop command functions' return values
For qemu-io, a function returns an integer with two possible values: 0
for "qemu-io may continue execution", or 1 for "qemu-io should exit".
However, there is only a single command that returns 1, and that is
"quit".
So let's turn this case into a global variable instead so we can make
better use of the return value in a later patch.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509194302.21585-2-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 20:00:59 +0000 (22:00 +0200)]
iotests: Repairing error during snapshot deletion
This adds a test for an I/O error during snapshot deletion, and maybe
more importantly, for how to repair the resulting image. If the
snapshot has been deleted before the error occurs, the only negative
result will be leaked clusters -- and those should be repairable with
qemu-img check -r leaks.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509200059.31125-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 20:00:58 +0000 (22:00 +0200)]
qcow2: Repair OFLAG_COPIED when fixing leaks
Repairing OFLAG_COPIED is usually safe because it is done after the
refcounts have been repaired. Therefore, it we did not find anyone else
referencing a data or L2 cluster, it makes no sense to not set
OFLAG_COPIED -- and the other direction (clearing OFLAG_COPIED) is
always safe, anyway, it may just induce leaks.
Furthermore, if OFLAG_COPIED is actually consistent with a wrong (leaky)
refcount, we will decrement the refcount with -r leaks, but OFLAG_COPIED
will then be wrong. qemu-img check should not produce images that are
more corrupted afterwards then they were before.
Max Reitz [Wed, 9 May 2018 21:00:23 +0000 (23:00 +0200)]
iotests: Rework 113
This test case has been broken since 398e6ad014df261d (roughly half a
year). qemu-img amend requires its output image to be R/W, so it opens
it as such; the node is then turned into an read-only node automatically
which is now accompanied by a warning, however. This warning has not
been part of the reference output.
For one thing, this warning shows that we cannot keep the test case as
it is. We would need a format that has no create_opts but that does
have write support -- we do not have such a format, though.
Another thing is that qemu now actually checks whether an image format
supports amendment instead of whether it has create_opts (since the
former always implies the latter). So we can now use any format that
does not support amendment (even if it supports creation) and thus test
the same code path.
The reason nobody has noticed the breakage until now of course is the
fact that nobody runs the iotests for nbd+bochs. There actually was
never any reason to set the protocol to "nbd" but because that was
technically correct; functionally it made no difference. So that is the
first thing we are going to change: Make the protocol "file" instead so
that people might actually notice breakage here.
Secondly, now that bochs no longer works for the amend test case, we
have to change the format there anyway. Set let us just bend the truth
a bit, declare this test a raw test. In fact, that does not even
concern the bochs test cases, other than the output now reading 'bochs'
instead of 'IMGFMT'.
So with this test now being a raw test, we can rework the amend test
case to use raw instead.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20180509210023.20283-8-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 21:00:22 +0000 (23:00 +0200)]
iotests: Test help option for unsupporting formats
This adds test cases to 082 for qemu-img create/convert/amend "-o help"
on formats that do not support creation or amendment, respectively.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509210023.20283-7-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Wed, 9 May 2018 21:00:21 +0000 (23:00 +0200)]
qemu-img: Recognize no creation support in -o help
The only users of print_block_option_help() are qemu-img create and
qemu-img convert for the output image, so this function is always used
for image creation (it used to be used for amendment also, but that is
no longer the case).
So if image creation is not supported by either the format or the
protocol, there is no need to print any option description, because the
user cannot create an image like this anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509210023.20283-6-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
projects / mirror_qemu.git / log