Peter Maydell [Wed, 23 Oct 2019 12:39:08 +0000 (13:39 +0100)]
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-10-22-v3' into staging
QAPI patches for 2019-10-22
# gpg: Signature made Tue 22 Oct 2019 15:56:36 BST
# gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg: issuer "armbru@redhat.com"
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* remotes/armbru/tags/pull-qapi-2019-10-22-v3:
qapi: Allow introspecting fix for savevm's cooperation with blockdev
tests/qapi-schema: Cover feature documentation comments
tests: qapi: Test 'features' of commands
qapi: Add feature flags to commands
tests/qapi-schema: Tidy up test output indentation
qapi: Clear scripts/qapi/doc.py executable bits again
qapi: Split up scripts/qapi/common.py
qapi: Move gen_enum(), gen_enum_lookup() back to qapi/types.py
qapi: Speed up frontend tests
qapi: Eliminate accidental global frontend state
qapi: Store pragma state in QAPISourceInfo, not global state
qapi: Don't suppress doc generation without pragma doc-required
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 22 Oct 2019 16:50:39 +0000 (17:50 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20191022-2' into staging
* Fix sign-extension for SMLAL* instructions
* Various ptimer device conversions to new transaction API
* Add a dummy Samsung SDHCI controller model to exynos4 boards
* Minor refactorings of RAM creation for some arm boards
* remotes/pmaydell/tags/pull-target-arm-20191022-2:
hw/arm/digic4: Inline digic4_board_setup_ram() function
hw/arm/omap1: Create the RAM in the board
hw/arm/omap2: Create the RAM in the board
hw/arm/collie: Create the RAM in the board
hw/arm/mps2: Use the IEC binary prefix definitions
hw/arm/xilinx_zynq: Use the IEC binary prefix definitions
hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
hw/sd/sdhci: Add dummy Samsung SDHCI controller
hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
hw/m68k/mcf5208.c: Switch to transaction-based ptimer API
hw/watchdog/etraxfs_timer.c: Switch to transaction-based ptimer API
hw/timer/altera_timer.c: Switch to transaction-based ptimer API
hw/timer/lm32_timer: Switch to transaction-based ptimer API
hw/timer/sh_timer: Switch to transaction-based ptimer API
hw/timer/puv3_ost.c: Switch to transaction-based ptimer API
hw/timer/arm_mptimer.c: Undo accidental rename of arm_mptimer_init()
hw/timer/exynos4210_mct: Initialize ptimer before starting it
target/arm: Fix sign-extension for SMLAL*
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:38 +0000 (16:50 +0100)]
hw/arm/digic4: Inline digic4_board_setup_ram() function
Having the RAM creation code in a separate function is not
very helpful. Move this code directly inside the board_init()
function, this will later allow the board to have the QOM
ownership of the RAM.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-7-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:38 +0000 (16:50 +0100)]
hw/arm/omap1: Create the RAM in the board
The SDRAM is incorrectly created in the OMAP310 SoC.
Move its creation in the board code, this will later allow the
board to have the QOM ownership of the RAM.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-6-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:38 +0000 (16:50 +0100)]
hw/arm/omap2: Create the RAM in the board
The SDRAM is incorrectly created in the OMAP2420 SoC.
Move its creation in the board code, this will later allow the
board to have the QOM ownership of the RAM.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-5-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:38 +0000 (16:50 +0100)]
hw/arm/collie: Create the RAM in the board
The SDRAM is incorrectly created in the SA1110 SoC.
Move its creation in the board code, this will later allow the
board to have the QOM ownership of the RAM.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-4-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:37 +0000 (16:50 +0100)]
hw/arm/mps2: Use the IEC binary prefix definitions
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-3-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:37 +0000 (16:50 +0100)]
hw/arm/xilinx_zynq: Use the IEC binary prefix definitions
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191021190653.9511-2-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:37 +0000 (16:50 +0100)]
hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
The Exynos SoC has specific SDHCI registers. Use the s3c SDHCI
model which handle these specific registers.
This silents the following "SDHC ... not implemented" warnings so
we can focus on the important registers missing:
$ qemu-system-arm ... -d unimp \
-append "... root=/dev/mmcblk0 rootfstype=ext4 rw rootwait" \
-drive file=linux-build-test/rootfs/arm/rootfs-armv5.ext2,if=sd,format=raw
[...]
[ 25.744858] sdhci: Secure Digital Host Controller Interface driver
[ 25.745862] sdhci: Copyright(c) Pierre Ossman
[ 25.783188] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (12000000 Hz)
SDHC rd_4b @0x80 not implemented
SDHC wr_4b @0x80 <- 0x00000020 not implemented
SDHC wr_4b @0x8c <- 0x00030000 not implemented
SDHC rd_4b @0x80 not implemented
SDHC wr_4b @0x80 <- 0xc0004100 not implemented
SDHC wr_4b @0x84 <- 0x80808080 not implemented
[ 26.013318] mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA
[ 26.032318] Synopsys Designware Multimedia Card Interface Driver
[ 42.024885] Waiting for root device /dev/mmcblk0...
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Message-id: 20191005154748.21718-5-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:37 +0000 (16:50 +0100)]
hw/sd/sdhci: Add dummy Samsung SDHCI controller
The Linux kernel access few S3C-specific registers [1] to set some
clock. We don't care about this part for device emulation [2]. Add
a dummy device to properly ignore these accesses, so we can focus
on the important registers missing.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Message-id: 20191005154748.21718-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Tue, 22 Oct 2019 15:50:37 +0000 (16:50 +0100)]
hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
This file keeps the various QDev blocks separated by comments.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cleber Rosa <crosa@redhat.com>
Message-id: 20191005154748.21718-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 22 Oct 2019 15:50:36 +0000 (16:50 +0100)]
hw/m68k/mcf5208.c: Switch to transaction-based ptimer API
Switch the mcf5208 code away from bottom-half based ptimers to
the new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the timer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Huth <huth@tuxfamily.org>
Message-id: 20191017132905.5604-9-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:36 +0000 (16:50 +0100)]
hw/watchdog/etraxfs_timer.c: Switch to transaction-based ptimer API
Switch the etraxfs_timer code away from bottom-half based ptimers to
the new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the timer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017132905.5604-7-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:36 +0000 (16:50 +0100)]
hw/timer/altera_timer.c: Switch to transaction-based ptimer API
Switch the altera_timer code away from bottom-half based ptimers to
the new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the timer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017132905.5604-6-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:36 +0000 (16:50 +0100)]
hw/timer/lm32_timer: Switch to transaction-based ptimer API
Switch the lm32_timer code away from bottom-half based ptimers to the
new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the ytimer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017132905.5604-4-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:36 +0000 (16:50 +0100)]
hw/timer/sh_timer: Switch to transaction-based ptimer API
Switch the sh_timer code away from bottom-half based ptimers to the
new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the timer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017132905.5604-3-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:35 +0000 (16:50 +0100)]
hw/timer/puv3_ost.c: Switch to transaction-based ptimer API
Switch the puv3_ost code away from bottom-half based ptimers to the
new transaction-based ptimer API. This just requires adding
begin/commit calls around the various places that modify the ptimer
state, and using the new ptimer_init() function to create the timer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017132905.5604-2-peter.maydell@linaro.org
Peter Maydell [Tue, 22 Oct 2019 15:50:35 +0000 (16:50 +0100)]
hw/timer/arm_mptimer.c: Undo accidental rename of arm_mptimer_init()
In commit b01422622b we did an automated rename of the ptimer_init()
function to ptimer_init_with_bh(). Unfortunately this caught the
unrelated arm_mptimer_init() function. Undo that accidental
renaming.
Fixes: b01422622b7c7293196fdaf1dbb4f495af44ecf9 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191017133331.5901-1-peter.maydell@linaro.org
Guenter Roeck [Tue, 22 Oct 2019 15:50:35 +0000 (16:50 +0100)]
hw/timer/exynos4210_mct: Initialize ptimer before starting it
When booting a recent Linux kernel, the qemu message "Timer with delta
zero, disabling" is seen, apparently because a ptimer is started before
being initialized. Fix the problem by initializing the offending ptimer
before starting it.
The bug is effectively harmless in the old QEMUBH setup
because the sequence of events is:
* the delta zero means the timer expires immediately
* ptimer_reload() arranges for exynos4210_gfrc_event() to be called
* ptimer_reload() notices the zero delta and disables the timer
* later, the QEMUBH runs, and exynos4210_gfrc_event() correctly
configures the timer and restarts it
In the new transaction based API the bug is still harmless,
but differences of when the callback function runs mean the
message is not printed any more:
* ptimer_run() does nothing as it's inside a transaction block
* ptimer_transaction_commit() sees it has work to do and
calls ptimer_reload()
* the zero delta means the timer expires immediately
* ptimer_reload() calls exynos4210_gfrc_event() directly
* exynos4210_gfrc_event() configures the timer
* the delta is no longer zero so ptimer_reload() doesn't complain
(the zero-delta test is after the trigger-callback in
the ptimer_reload() function)
Regardless, the behaviour here was not intentional, and we should
just program the ptimer correctly to start with.
Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20191018143149.9216-1-peter.maydell@linaro.org
[PMM: Expansion/clarification of the commit message:
the message is about a zero delta, not a zero period;
added detail to the commit message of the analysis of what
is happening and why the kernel boots even with the message;
added note that the message goes away with the new ptimer API] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Krempa [Fri, 18 Oct 2019 08:14:54 +0000 (10:14 +0200)]
qapi: Allow introspecting fix for savevm's cooperation with blockdev
'savevm' was buggy as it considered all monitor-owned block device
nodes for snapshot. With the introduction of -blockdev, the common
usage made all nodes including protocol and backing file nodes be
monitor-owned and thus considered for snapshot.
This is a problem since the 'file' protocol nodes can't have internal
snapshots and it does not make sense to take snapshot of nodes
representing backing files.
This was fixed by commit 05f4aced658a02b02. Clients need to be able to
detect whether this fix is present.
Since savevm does not have an QMP alternative, add the feature for the
'human-monitor-command' backdoor which is used to call this command in
modern use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191018081454.21369-6-armbru@redhat.com>
Commit 8aa3a33e44 "tests/qapi-schema: Test for good feature lists in
structs" neglected to cover documentation comments, and the previous
commit followed its example. Make up for them.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191018081454.21369-5-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Peter Krempa [Fri, 18 Oct 2019 08:14:52 +0000 (10:14 +0200)]
tests: qapi: Test 'features' of commands
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191018081454.21369-4-armbru@redhat.com>
Peter Krempa [Fri, 18 Oct 2019 08:14:51 +0000 (10:14 +0200)]
qapi: Add feature flags to commands
Similarly to features for struct types introduce the feature flags also
for commands. This will allow notifying management layers of fixes and
compatible changes in the behaviour of a command which may not be
detectable any other way.
The changes were heavily inspired by commit 6a8c0b51025.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191018081454.21369-3-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 08:14:50 +0000 (10:14 +0200)]
tests/qapi-schema: Tidy up test output indentation
Command and event details are indented three spaces, everything else
four. Messed up in commit 156402e5042. Use four spaces consistently.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Message-Id: <20191018081454.21369-2-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:45 +0000 (09:43 +0200)]
qapi: Clear scripts/qapi/doc.py executable bits again
Commit fbf09a2fa4 "qapi: add 'ifcond' to visitor methods" brought back
the executable bits. Fix that. Drop the #! line for good measure.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-8-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:44 +0000 (09:43 +0200)]
qapi: Split up scripts/qapi/common.py
The QAPI code generator clocks in at some 3100 SLOC in 8 source files.
Almost 60% of the code is in qapi/common.py. Split it into more
focused modules:
* Move QAPISchemaPragma and QAPISourceInfo to qapi/source.py.
* Move QAPIError and its sub-classes to qapi/error.py.
* Move QAPISchemaParser and QAPIDoc to parser.py. Use the opportunity
to put QAPISchemaParser first.
* Move check_expr() & friends to qapi/expr.py. Use the opportunity to
put the code into a more sensible order.
* Move QAPISchema & friends to qapi/schema.py
* Move QAPIGen and its sub-classes, ifcontext,
QAPISchemaModularCVisitor, and QAPISchemaModularCVisitor to qapi/gen.py
* Delete camel_case(), it's unused since commit e98859a9b9 "qapi:
Clean up after recent conversions to QAPISchemaVisitor"
A number of helper functions remain in qapi/common.py. I considered
moving the code generator helpers to qapi/gen.py, but decided not to.
Perhaps we should rewrite them as methods of QAPIGen some day.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-7-armbru@redhat.com>
[Add "# -*- coding: utf-8 -*-" lines]
* remotes/vivier2/tags/trivial-branch-pull-request:
tests/migration: fix a typo in comment
qemu-doc: Remove paragraph about requiring a HD image with -kernel
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Markus Armbruster [Fri, 18 Oct 2019 07:43:43 +0000 (09:43 +0200)]
qapi: Move gen_enum(), gen_enum_lookup() back to qapi/types.py
The next commit will split up qapi/common.py. gen_enum() needs
QAPISchemaEnumMember, and that's in the way. Move it to qapi/types.py
along with its buddy gen_enum_lookup().
Permit me a short a digression on history: how did gen_enum() end up
in qapi/common.py? Commit 21cd70dfc1 "qapi script: add event support"
duplicated qapi-types.py's gen_enum() and gen_enum_lookup() in
qapi-event.py. Simply importing them would have been cleaner, but
wasn't possible as qapi-types.py was a program, not a module. Commit efd2eaa6c2 "qapi: De-duplicate enum code generation" de-duplicated by
moving them to qapi.py, which was a module.
Since then, program qapi-types.py has morphed into module types.py.
It's where gen_enum() and gen_enum_lookup() started, and where they
belong.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-6-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:42 +0000 (09:43 +0200)]
qapi: Speed up frontend tests
"make check-qapi-schema" takes around 10s user + system time for me.
With -j, it takes a bit over 3s real time. We have worse tests. It's
still annoying when you work on the QAPI generator.
Some 1.4s user + system time is consumed by make figuring out what to
do, measured by making a target that does nothing. There's nothing I
can do about that right now. But let's see what we can do about the
other 8s.
Almost 7s are spent running test-qapi.py for every test case, the rest
normalizing and diffing test-qapi.py output. We have 190 test cases.
If I downgrade to python2, it's 4.5s, but python2 is a goner.
Hacking up test-qapi.py to exit(0) without doing anything makes it
only marginally faster. The problem is Python startup overhead.
Our configure puts -B into $(PYTHON). Running without -B is faster:
4.4s.
We could improve the Makefile to run test cases only when the test
case or the generator changed. But I'm after improvement in the case
where the generator changed.
test-qapi.py is designed to be the simplest possible building block
for a shell script to do the complete job (it's actually a Makefile,
not a shell script; no real difference). Python is just not meant for
that. It's for bigger blocks.
Move the post-processing and diffing into test-qapi.py, and make it
capable of testing multiple schema files. Set executable bits while
there.
Running it once per test case now takes slightly longer than 8s. But
running it once for all of them takes under 0.2s.
Messing with the Makefile to run it only on the tests that need
retesting is clearly not worth the bother.
Expected error output changes because the new normalization strips off
$(SRCDIR)/tests/qapi-schema/ instead of just $(SRCDIR)/.
The .exit files go away, because there is no exit status to test
anymore.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-5-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:41 +0000 (09:43 +0200)]
qapi: Eliminate accidental global frontend state
The frontend can't be run more than once due to its global state.
A future commit will want to do that.
The only global frontend state remaining is accidental:
QAPISchemaParser.__init__()'s parameter previously_included=[].
Python evaluates the default once, at definition time. Any
modifications to it are visible in subsequent calls. Well-known
Python trap. Change the default to None and replace it by the real
default in the function body. Use the opportunity to convert
previously_included to a set.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-4-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:40 +0000 (09:43 +0200)]
qapi: Store pragma state in QAPISourceInfo, not global state
The frontend can't be run more than once due to its global state.
A future commit will want to do that.
Recent commit "qapi: Move context-sensitive checking to the proper
place" got rid of many global variables already, but pragma state is
still stored in global variables (that's why a pragma directive's
scope is the complete schema).
Move the pragma state to QAPISourceInfo.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-3-armbru@redhat.com>
Markus Armbruster [Fri, 18 Oct 2019 07:43:39 +0000 (09:43 +0200)]
qapi: Don't suppress doc generation without pragma doc-required
Commit bc52d03ff5 "qapi: Make doc comments optional where we don't
need them" made scripts/qapi2texi.py fail[*] unless the schema had
pragma 'doc-required': true. The stated reason was inability to cope
with incomplete documentation.
When commit fb0bc835e5 "qapi-gen: New common driver for code and doc
generators" folded scripts/qapi2texi.py into scripts/qapi-gen.py, it
turned the failure into silent suppression.
The doc generator can cope with incomplete documentation now. I don't
know since when, or what the problem was, or even whether it ever
existed.
Drop the silent suppression.
[*] The fail part was broken, fixed in commit e8ba07ea9a.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191018074345.24034-2-armbru@redhat.com>
Thomas Huth [Tue, 1 Oct 2019 11:01:11 +0000 (13:01 +0200)]
qemu-doc: Remove paragraph about requiring a HD image with -kernel
The need for specifying "-hda" together with "-kernel" has been removed in
commit 57a46d057995 ("Convert linux bootrom to external rom and fw_cfg"),
almost 10 years ago, so let's remove this description from our documentation
now, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191001110111.4870-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
David Hildenbrand [Mon, 21 Oct 2019 10:05:15 +0000 (12:05 +0200)]
s390x/kvm: Set default cpu model for all machine classes
We have to set the default model of all machine classes, not just for
the active one. Otherwise, "query-machines" will indicate the wrong
CPU model ("qemu-s390x-cpu" instead of "host-s390x-cpu") as
"default-cpu-type".
Doing a
{"execute":"query-machines"}
under KVM now results in
{"return": [
{
"hotpluggable-cpus": true,
"name": "s390-ccw-virtio-4.0",
"numa-mem-supported": false,
"default-cpu-type": "host-s390x-cpu",
"cpu-max": 248,
"deprecated": false},
{
"hotpluggable-cpus": true,
"name": "s390-ccw-virtio-2.7",
"numa-mem-supported": false,
"default-cpu-type": "host-s390x-cpu",
"cpu-max": 248,
"deprecated": false
} ...
Libvirt probes all machines via "-machine none,accel=kvm:tcg" and will
currently see the wrong CPU model under KVM.
Reported-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Fixes: b6805e127c6b ("s390x: use generic cpu_model parsing") Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021100515.6978-1-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
David Hildenbrand [Mon, 21 Oct 2019 08:57:15 +0000 (10:57 +0200)]
s390x/tcg: Fix VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION
The numbers are unsigned, the computation is wrong. "Each operand is
treated as an unsigned binary integer".
Let's implement as given in the PoP:
"A subtraction is performed by adding the contents of the second operand
with the bitwise complement of the third operand along with a borrow
indication from the rightmost bit of the fourth operand."
Reuse gen_accc2_i64().
Fixes: bc725e65152c ("s390x/tcg: Implement VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION") Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-7-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
David Hildenbrand [Mon, 21 Oct 2019 08:57:14 +0000 (10:57 +0200)]
s390x/tcg: Fix VECTOR SUBTRACT WITH BORROW INDICATION
Testing this, there seems to be something messed up. We are dealing with
unsigned numbers. "Each operand is treated as an unsigned binary integer."
Let's just implement as written in the PoP:
"A subtraction is performed by adding the contents of
the second operand with the bitwise complement of
the third operand along with a borrow indication from
the rightmost bit position of the fourth operand and
the result is placed in the first operand."
We can reuse gen_ac2_i64().
Fixes: 48390a7c2716 ("s390x/tcg: Implement VECTOR SUBTRACT WITH BORROW INDICATION") Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-6-david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Looks like my idea of what a "borrow" is was wrong. The PoP says:
"If the resulting subtraction results in a carry out of bit zero, a value
of one is placed in the corresponding element of the first operand;
otherwise, a value of zero is placed in the corresponding element"
As clarified by Richard, all we have to do is invert the result.
Andrew Jones [Wed, 16 Oct 2019 14:54:34 +0000 (16:54 +0200)]
s390x/cpumodel: Add missing visit_free
Beata Michalska noticed this missing visit_free() while reviewing
arm's implementation of qmp_query_cpu_model_expansion(), which is
modeled off this s390x implementation.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20191016145434.7007-1-drjones@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Shu-Chun Weng [Fri, 18 Oct 2019 00:19:20 +0000 (17:19 -0700)]
Fix unsigned integer underflow in fd-trans.c
In any of these `*_for_each_*` functions, the last entry in the buffer (so the
"remaining length in the buffer" `len` is equal to the length of the
entry `nlmsg_len`/`nla_len`/etc) has size that is not a multiple of the
alignment, the aligned lengths `*_ALIGN(*_len)` will be greater than `len`.
Since `len` is unsigned (`size_t`), it underflows and the loop will read
pass the buffer.
This may manifest as random EINVAL or EOPNOTSUPP error on IO or network
system calls.
* remotes/kraxel/tags/audio-20191018-pull-request:
paaudio: fix channel order for usb-audio 5.1 and 7.1 streams
usbaudio: change playback counters to 64 bit
usb-audio: support more than two channels of audio
usb-audio: do not count on avail bytes actually available
audio: basic support for multichannel audio
audio: replace shift in audio_pcm_info with bytes_per_frame
audio: support more than two channels in volume setting
paaudio: get/put_buffer functions
audio: make mixeng optional
audio: add mixing-engine option (documentation)
audio: paaudio: ability to specify stream name
audio: paaudio: fix connection and stream name
audio: fix parameter dereference before NULL check
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/jnsnow/tags/bitmaps-pull-request:
dirty-bitmaps: remove deprecated autoload parameter
MAINTAINERS: Add Vladimir as a reviewer for bitmaps
qcow2-bitmap: move bitmap reopen-rw code to qcow2_reopen_commit
block/qcow2-bitmap: fix and improve qcow2_reopen_bitmaps_rw
iotests: add test 260 to check bitmap life after snapshot + commit
block/qcow2-bitmap: do not remove bitmaps on reopen-ro
block/qcow2-bitmap: drop qcow2_reopen_bitmaps_rw_hint()
block/qcow2-bitmap: get rid of bdrv_has_changed_persistent_bitmaps
iotests: add test-case to 165 to test reopening qcow2 bitmaps to RW
block: reverse order for reopen commits
block: switch reopen queue from QSIMPLEQ to QTAILQ
block/dirty-bitmap: refactor bdrv_dirty_bitmap_next
block/dirty-bitmap: drop BdrvDirtyBitmap.mutex
block/dirty-bitmap: add bs link
block/dirty-bitmap: drop meta
block/qcow2: proper locking on bitmap add/remove paths
block/dirty-bitmap: return int from bdrv_remove_persistent_dirty_bitmap
block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c
util/hbitmap: strict hbitmap_reset
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/kraxel/tags/ui-20191018-pull-request:
ui: fix keymap file search in input-barrier object
curses: correctly pass the color pair to setcchar()
curses: use the bit mask constants provided by curses
ui: Fix hanging up Cocoa display on macOS 10.15 (Catalina)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Matthew Kilgore [Fri, 4 Oct 2019 03:53:38 +0000 (23:53 -0400)]
curses: correctly pass the color pair to setcchar()
The current code does not correctly pass the color pair information to
setcchar(), it instead always passes zero. This results in the curses
output always being in white on black.
This patch fixes this by using PAIR_NUMBER() to retrieve the color pair
number from the chtype value, and then passes that value as an argument
to setcchar().
Signed-off-by: Matthew Kilgore <mattkilgore12@gmail.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-id: 20191004035338.25601-3-mattkilgore12@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Matthew Kilgore [Fri, 4 Oct 2019 03:53:37 +0000 (23:53 -0400)]
curses: use the bit mask constants provided by curses
The curses API provides the A_ATTRIBUTES and A_CHARTEXT bit masks for
getting the attributes and character parts of a chtype, respectively. We
should use provided constants instead of using 0xff.
Signed-off-by: Matthew Kilgore <mattkilgore12@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-id: 20191004035338.25601-2-mattkilgore12@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Hikaru Nishida [Tue, 15 Oct 2019 01:07:34 +0000 (10:07 +0900)]
ui: Fix hanging up Cocoa display on macOS 10.15 (Catalina)
macOS API documentation says that before applicationDidFinishLaunching
is called, any events will not be processed. However, some events are
fired before it is called in macOS Catalina. This causes deadlock of
iothread_lock in handleEvent while it will be released after the
app_started_sem is posted.
This patch avoids processing events before the app_started_sem is
posted to prevent this deadlock.
Kővágó, Zoltán [Sun, 13 Oct 2019 19:58:06 +0000 (21:58 +0200)]
usbaudio: change playback counters to 64 bit
With stereo playback, they need about 375 minutes of continuous audio
playback to overflow, which is usually not a problem (as stopping and
later resuming playback resets the counters). But with 7.1 audio, they
only need about 95 minutes to overflow.
After the overflow, the buf->prod % USBAUDIO_PACKET_SIZE(channels)
assertion no longer holds true, which will result in overflowing the
buffer. With 64 bit variables, it would take about 762000 years to
overflow.
Kővágó, Zoltán [Sun, 13 Oct 2019 19:58:05 +0000 (21:58 +0200)]
usb-audio: support more than two channels of audio
This commit adds support for 5.1 and 7.1 audio playback. This commit
adds a new property to usb-audio:
* multi=on|off
Whether to enable the 5.1 and 7.1 audio support. When off (default)
it continues to emulate the old stereo-only device. When on, it
emulates a slightly different audio device that supports 5.1 and 7.1
audio.
Kővágó, Zoltán [Sun, 13 Oct 2019 19:58:02 +0000 (21:58 +0200)]
audio: replace shift in audio_pcm_info with bytes_per_frame
The bit shifting trick worked because the number of bytes per frame was
always a power-of-two (since QEMU only supports mono, stereo and 8, 16
and 32 bit samples). But if we want to add support for surround sound,
this no longer holds true.
Kővágó, Zoltán [Sun, 13 Oct 2019 19:57:58 +0000 (21:57 +0200)]
audio: add mixing-engine option (documentation)
This will allow us to disable mixeng when we use a decent backend.
Disabling mixeng have a few advantages:
* we no longer convert the audio output from one format to another, when
the underlying audio system would just convert it to a third format.
We no longer convert, only the underlying system, when needed.
* the underlying system probably has better resampling and sample format
converting methods anyway...
* we may support formats that the mixeng currently does not support (S24
or float samples, more than two channels)
* when using an audio server (like pulseaudio) different sound card
outputs will show up as separate streams, even if we use only one
backend
Disadvantages:
* audio capturing no longer works (wavcapture, and vnc audio extension)
* some backends only support a single playback stream or very picky
about the audio format. In this case we can't disable mixeng.
Originally thw two main use cases of the disabled option was: using
unsupported audio formats (5.1 and 7.1 audio) and having different
pulseaudio streams per audio frontend. Since we can have multiple
-audiodevs, the latter is not that important, so currently you only need
this option if you want to use 5.1 or 7.1 audio (implemented in a later
patch), otherwise it's probably better to stick to the old and tried
mixeng, since it's less picky about the backends.
The ideal solution would be to port as much as possible to gstreamer,
but this is currently out of scope:
https://wiki.qemu.org/Internships/ProjectIdeas/AudioGStreamer
Kővágó, Zoltán [Tue, 10 Sep 2019 23:26:19 +0000 (01:26 +0200)]
audio: paaudio: fix connection and stream name
Connection name was previously erroneously set to the server socket
path, while connection names were simply "qemu". After this patch, the
connection name will be the vm name (falling back to "qemu" if not
specified), while stream names will be the audiodev's id.
This parameter has been deprecated since 2.12.0 and is eligible for
removal. Remove this parameter as it is actually completely ignored;
let's not give false hope.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191002232411.29968-1-jsnow@redhat.com
John Snow [Sat, 5 Oct 2019 19:44:48 +0000 (15:44 -0400)]
MAINTAINERS: Add Vladimir as a reviewer for bitmaps
I already try to make sure all bitmaps patches have been reviewed by both
Red Hat and Virtuozzo anyway, so this formalizes the arrangement.
Fam meanwhile is no longer as active, so I am removing him as a co-maintainer
simply to reflect the current practice.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191005194448.16629-2-jsnow@redhat.com
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:55 +0000 (15:23 +0300)]
qcow2-bitmap: move bitmap reopen-rw code to qcow2_reopen_commit
The only reason I can imagine for this strange code at the very-end of
bdrv_reopen_commit is the fact that bs->read_only updated after
calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same
time, prior to previous commit, qcow2_reopen_bitmaps_rw did a wrong
check for being writable, when actually it only need writable file
child not self.
So, as it's fixed, let's move things to correct place.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Acked-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190927122355.7344-10-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:54 +0000 (15:23 +0300)]
block/qcow2-bitmap: fix and improve qcow2_reopen_bitmaps_rw
- Correct check for write access to file child, and in correct place
(only if we want to write).
- Support reopen rw -> rw (which will be used in following commit),
for example, !bdrv_dirty_bitmap_readonly() is not a corruption if
bitmap is marked IN_USE in the image.
- Consider unexpected bitmap as a corruption and check other
combinations of in-image and in-RAM bitmaps.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190927122355.7344-9-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:53 +0000 (15:23 +0300)]
iotests: add test 260 to check bitmap life after snapshot + commit
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190927122355.7344-8-vsementsov@virtuozzo.com
[Maintainer edit: removed 260 from auto group per Peter Maydell. --js] Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:52 +0000 (15:23 +0300)]
block/qcow2-bitmap: do not remove bitmaps on reopen-ro
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the following bug:
Assume we have persistent bitmap 'bitmap0'.
Create external snapshot
bitmap0 is stored and therefore removed
Commit snapshot
now we have no bitmaps
Do some writes from guest (*)
they are not marked in bitmap
Shutdown
Start
bitmap0 is loaded as valid, but it is actually broken! It misses
writes (*)
Incremental backup
it will be inconsistent
So, let's stop removing bitmaps on reopen-ro. But don't rejoice:
reopening bitmaps to rw is broken too, so the whole scenario will not
work after this patch and we can't enable corresponding test cases in
260 iotests still. Reopening bitmaps rw will be fixed in the following
patches.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190927122355.7344-7-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:51 +0000 (15:23 +0300)]
block/qcow2-bitmap: drop qcow2_reopen_bitmaps_rw_hint()
The function is unused, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190927122355.7344-6-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:50 +0000 (15:23 +0300)]
block/qcow2-bitmap: get rid of bdrv_has_changed_persistent_bitmaps
Firstly, no reason to optimize failure path. Then, function name is
ambiguous: it checks for readonly and similar things, but someone may
think that it will ignore normal bitmaps which was just unchanged, and
this is in bad relation with the fact that we should drop IN_USE flag
for unchanged bitmaps in the image.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190927122355.7344-5-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:49 +0000 (15:23 +0300)]
iotests: add test-case to 165 to test reopening qcow2 bitmaps to RW
Reopening bitmaps to RW was broken prior to previous commit. Check that
it works now.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190927122355.7344-4-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:48 +0000 (15:23 +0300)]
block: reverse order for reopen commits
It's needed to fix reopening qcow2 with bitmaps to RW. Currently it
can't work, as qcow2 needs write access to file child, to mark bitmaps
in-image with IN_USE flag. But usually children goes after parents in
reopen queue and file child is still RO on qcow2 reopen commit. Reverse
reopen order to fix it.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Acked-by: Max Reitz <mreitz@redhat.com> Acked-by: John Snow <jsnow@redhat.com>
Message-id: 20190927122355.7344-3-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 27 Sep 2019 12:23:47 +0000 (15:23 +0300)]
block: switch reopen queue from QSIMPLEQ to QTAILQ
We'll need reverse-foreach in the following commit, QTAILQ support it,
so move to QTAILQ.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190927122355.7344-2-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
bdrv_dirty_bitmap_next is always used in same pattern. So, split it
into _next and _first, instead of combining two functions into one and
add FOR_EACH_DIRTY_BITMAP macro.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190916141911.5255-5-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Mon, 16 Sep 2019 14:19:10 +0000 (17:19 +0300)]
block/dirty-bitmap: drop BdrvDirtyBitmap.mutex
mutex field is just a pointer to bs->dirty_bitmap_mutex, so no needs
to store it in BdrvDirtyBitmap when we have bs pointer in it (since
previous patch).
Drop mutex field. Constantly use bdrv_dirty_bitmaps_lock/unlock in
block/dirty-bitmap.c to make it more obvious that it's not per-bitmap
lock. Still, for simplicity, leave bdrv_dirty_bitmap_lock/unlock
functions as an external API.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190916141911.5255-4-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Mon, 16 Sep 2019 14:19:09 +0000 (17:19 +0300)]
block/dirty-bitmap: add bs link
Add bs field to BdrvDirtyBitmap structure. Drop BlockDriverState
parameter from bitmap APIs where possible.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190916141911.5255-3-vsementsov@virtuozzo.com
[Rebased on top of block-copy. --js] Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Mon, 16 Sep 2019 14:19:08 +0000 (17:19 +0300)]
block/dirty-bitmap: drop meta
Drop meta bitmaps, as they are unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190916141911.5255-2-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 20 Sep 2019 08:25:43 +0000 (11:25 +0300)]
block/qcow2: proper locking on bitmap add/remove paths
qmp_block_dirty_bitmap_add and do_block_dirty_bitmap_remove do acquire
aio context since 0a6c86d024c52b. But this is not enough: we also must
lock qcow2 mutex when access in-image metadata. Especially it concerns
freeing qcow2 clusters.
To achieve this, move qcow2_can_store_new_dirty_bitmap and
qcow2_remove_persistent_dirty_bitmap to coroutine context.
Since we work in coroutines in correct aio context, we don't need
context acquiring in blockdev.c anymore, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190920082543.23444-4-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 20 Sep 2019 08:25:42 +0000 (11:25 +0300)]
block/dirty-bitmap: return int from bdrv_remove_persistent_dirty_bitmap
It's more comfortable to not deal with local_err.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190920082543.23444-3-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Fri, 20 Sep 2019 08:25:41 +0000 (11:25 +0300)]
block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c
block/dirty-bitmap.c seems to be more appropriate for it and
bdrv_remove_persistent_dirty_bitmap already in it.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190920082543.23444-2-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
Vladimir Sementsov-Ogievskiy [Tue, 6 Aug 2019 15:26:11 +0000 (18:26 +0300)]
util/hbitmap: strict hbitmap_reset
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs, like in recently fixed write-blocking mode of
mirror: user calls reset on unaligned region, not keeping in mind that
there are possible unrelated dirty bytes, covered by rounded-up region
and information of this unrelated "dirtiness" will be lost.
Make hbitmap_reset strict: assert that arguments are aligned, allowing
only one exception when @start + @count == hb->orig_size. It's needed
to comfort users of hbitmap_next_dirty_area, which cares about
hb->orig_size.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20190806152611.280389-1-vsementsov@virtuozzo.com>
[Maintainer edit: Max's suggestions from on-list. --js]
[Maintainer edit: Eric's suggestion for aligned macro. --js] Signed-off-by: John Snow <jsnow@redhat.com>
# gpg: Signature made Tue 15 Oct 2019 22:35:43 BST
# gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
# gpg: issuer "ehabkost@redhat.com"
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/machine-next-pull-request:
target/i386: Add Snowridge-v2 (no MPX) CPU model
i386: Omit all-zeroes entries from KVM CPUID table
i386: Fix legacy guest with xsave panic on host kvm without update cpuid.
target/i386: drop the duplicated definition of cpuid AVX512_VBMI macro
target/i386: clean up comments over 80 chars per line
memory-device: break the loop if tmp exceed the hinted range
memory-device: not necessary to use goto for the last check
hw/misc/vmcoreinfo: Add comment about reset handler
hw/input/lm832x: Convert reset handler to DeviceReset
hw/isa/vt82c686: Convert reset handler to DeviceReset
hw/ide/via82c: Convert reset handler to DeviceReset
hw/ide/sii3112: Convert reset handler to DeviceReset
hw/ide/piix: Convert reset handler to DeviceReset
hw/isa/piix4: Convert reset handler to DeviceReset
hw/acpi/piix4: Convert reset handler to DeviceReset
numa: Introduce MachineClass::auto_enable_numa for implicit NUMA node
tests: cpu-plug-test: fix device_add for pc/q35 machines
tests: add qtest_qmp_device_add_qdict() helper
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Thu, 17 Oct 2019 15:48:56 +0000 (16:48 +0100)]
Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20191013' into staging
Host vector support for tcg/ppc.
Fix thread=single cpu kicking.
# gpg: Signature made Mon 14 Oct 2019 15:11:55 BST
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* remotes/rth/tags/pull-tcg-20191013: (23 commits)
cpus: kick all vCPUs when running thread=single
tcg/ppc: Update vector support for v3.00 dup/dupi
tcg/ppc: Update vector support for v3.00 load/store
tcg/ppc: Update vector support for v3.00 Altivec
tcg/ppc: Update vector support for v2.07 FP
tcg/ppc: Update vector support for v2.07 VSX
tcg/ppc: Update vector support for v2.07 Altivec
tcg/ppc: Update vector support for VSX
tcg/ppc: Enable Altivec detection
tcg/ppc: Support vector dup2
tcg/ppc: Support vector multiply
tcg/ppc: Support vector shift by immediate
tcg/ppc: Add support for vector saturated add/subtract
tcg/ppc: Add support for vector add/subtract
tcg/ppc: Add support for vector maximum/minimum
tcg/ppc: Add support for load/store/logic/comparison
tcg/ppc: Enable tcg backend vector compilation
tcg/ppc: Replace HAVE_ISEL macro with a variable
tcg/ppc: Replace HAVE_ISA_2_06
tcg/ppc: Create TCGPowerISA and have_isa
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Thu, 17 Oct 2019 14:30:44 +0000 (15:30 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, vhost, acpi: features, fixes, tests
ARM ACPI memory hotplug support +
tests for new arm/virt ACPI tables.
Virtio fs support (no migration).
A vhost-user reconnect bugfix.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Tue 15 Oct 2019 22:02:19 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
virtio: add vhost-user-fs-pci device
virtio: add vhost-user-fs base device
virtio: Add virtio_fs linux headers
tests/acpi: add expected tables for arm/virt
tests: document how to update acpi tables
tests: Add bios tests to arm/virt
tests: allow empty expected files
tests/acpi: add empty files
tests: Update ACPI tables list for upcoming arm/virt tests
docs/specs: Add ACPI GED documentation
hw/arm: Use GED for system_powerdown event
hw/arm: Factor out powerdown notifier from GPIO
hw/arm/virt-acpi-build: Add PC-DIMM in SRAT
hw/arm/virt: Enable device memory cold/hot plug with ACPI boot
hw/arm/virt: Add memory hotplug framework
hw/acpi: Add ACPI Generic Event Device Support
hw/acpi: Do not create memory hotplug method when handler is not defined
hw/acpi: Make ACPI IO address space configurable
vhost-user: save features if the char dev is closed
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eduardo Habkost [Mon, 14 Oct 2019 15:01:33 +0000 (12:01 -0300)]
sphinx: Use separate doctree directories for different builders
sphinx-build is buggy when multiple processes are using the same
doctree directory in parallel. See the 3-year-old Sphinx bug
report at: https://github.com/sphinx-doc/sphinx/issues/2946
Instead of avoiding parallel builds or adding some kind of
locking, I'm using the simplest solution: just using a different
doctree cache for each builder.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20191014150133.14318-1-ehabkost@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>