David Gibson [Thu, 26 Sep 2019 04:11:23 +0000 (14:11 +1000)]
spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController
This method essentially represents code which belongs to the interrupt
controller, but needs to be called on all possible intcs, rather than
just the currently active one. The "dual" version therefore calls
into the xics and xive versions confusingly.
Handle this more directly, by making it instead a method on the intc
backend, and always calling it on every backend that exists.
While we're there, streamline the error reporting a bit.
The SpaprIrq structure is used to represent ths spapr machine's irq
backend. Except that it kind of conflates two concepts: one is the
backend proper - a specific interrupt controller that we might or
might not be using, the other is the irq configuration which covers
the layout of irq space and which interrupt controllers are allowed.
This leads to some pretty confusing code paths for the "dual"
configuration where its hooks redirect to other SpaprIrq structures
depending on the currently active irq controller.
To clean this up, we start by introducing a new
SpaprInterruptController QOM interface to represent strictly an
interrupt controller backend, not counting anything configuration
related. We implement this interface in the XICs and XIVE interrupt
controllers, and in future we'll move relevant methods from SpaprIrq
into it.
Greg Kurz [Thu, 3 Oct 2019 12:02:00 +0000 (14:02 +0200)]
spapr: Set VSMT to smp_threads by default
Support for setting VSMT is available in KVM since linux-4.13. Most distros
that support KVM on POWER already have it. It thus seem reasonable enough
to have the default machine to set VSMT to smp_threads.
This brings contiguous VCPU ids and thus brings their upper bound down to
the machine's max_cpus. This is especially useful for XIVE KVM devices,
which may thus allocate only one VP descriptor per VCPU.
ppc/pnv: Use address_space_stq_be() when triggering an interrupt from PSI
Include the XIVE_TRIGGER_PQ bit in the trigger data which is how
hardware signals to the IC that the PQ bits of the interrupt source
have been checked.
The trigger data is used for both triggers of a HW source interrupts,
PHB, PSI, and triggers for rerouting interrupts between interrupt
controllers.
When an interrupt is rerouted, the trigger data follows an "END
trigger" format. In that case, the remote IC needs EAS containing an
END index to perform a lookup of an END.
An END trigger, bit0 of word0 set to '1', is defined as :
|0123|4567|0123|4567|0123|4567|0123|4567|
W0 E=1 |1P--|BLOC| END IDX |
W1 E=1 |M | END DATA |
An EAS is defined as :
|0123|4567|0123|4567|0123|4567|0123|4567|
W0 |V---|BLOC| END IDX |
W1 |M | END DATA |
The END trigger adds an extra 'PQ' bit, bit1 of word0 set to '1',
signaling that the PQ bits have been checked. That bit is unused in
the initial EAS definition.
When a HW device performs the trigger, the trigger data follows an
"EAS trigger" format because the trigger data in that case contains an
EAS index which the IC needs to look for.
An EAS trigger, bit0 of word0 set to '0', is defined as :
|0123|4567|0123|4567|0123|4567|0123|4567|
W0 E=0 |0P--|---- ---- ---- ---- ---- ---- ----|
W1 E=0 |BLOC| EAS INDEX |
There is also a 'PQ' bit, bit1 of word0 to '1', signaling that the
PQ bits have been checked.
Introduce these new trigger bits and rename the XIVE_SRCNO macros in
XIVE_EAS to reflect better the nature of the data.
target/ppc: Fix for optimized vsl/vsr instructions
In previous implementation, invocation of TCG shift function could request
shift of TCG variable by 64 bits when variable 'sh' is 0, which is not
supported in TCG (values can be shifted by 0 to 63 bits). This patch fixes
this by using two separate invocation of TCG shift functions, with maximum
shift amount of 32.
Name of variable 'shifted' is changed to 'carry' so variable naming
is similar to old helper implementation.
Variables 'avrA' and 'avrB' are replaced with variable 'avr'.
Greg Kurz [Fri, 4 Oct 2019 08:37:47 +0000 (10:37 +0200)]
xics: Make some device types not user creatable
Some device types of the XICS model are exposed to the QEMU command
line:
$ ppc64-softmmu/qemu-system-ppc64 -device help | grep ic[sp]
name "icp"
name "ics"
name "ics-spapr"
name "pnv-icp", desc "PowerNV ICP"
These are internal devices that shouldn't be instantiable by the
user. By the way, they can't be because their respective realize
functions expect link properties that can't be set from the command
line:
qemu-system-ppc64: -device icp: required link 'xics' not found:
Property '.xics' not found
qemu-system-ppc64: -device ics: required link 'xics' not found:
Property '.xics' not found
qemu-system-ppc64: -device ics-spapr: required link 'xics' not found:
Property '.xics' not found
qemu-system-ppc64: -device pnv-icp: required link 'xics' not found:
Property '.xics' not found
Hide them by setting dc->user_creatable to false in the base class
"icp" and "ics" init functions.
Greg Kurz [Fri, 4 Oct 2019 07:38:50 +0000 (09:38 +0200)]
xive: Make some device types not user creatable
Some device types of the XIVE model are exposed to the QEMU command
line:
$ ppc64-softmmu/qemu-system-ppc64 -device help | grep xive
name "xive-end-source", desc "XIVE END Source"
name "xive-source", desc "XIVE Interrupt Source"
name "xive-tctx", desc "XIVE Interrupt Thread Context"
These are internal devices that shouldn't be instantiable by the
user. By the way, they can't be because their respective realize
functions expect link properties that can't be set from the command
line:
qemu-system-ppc64: -device xive-source: required link 'xive' not found:
Property '.xive' not found
qemu-system-ppc64: -device xive-end-source: required link 'xive' not found:
Property '.xive' not found
qemu-system-ppc64: -device xive-tctx: required link 'cpu' not found:
Property '.cpu' not found
Hide them by setting dc->user_creatable to false in their respective
class init functions.
* 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
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*
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Tested-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Peter Maydell <[email protected]>
Message-id: 20191018143149[email protected]
[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 <[email protected]>
1. add new modes:
connecting-wait: means, that reconnecting is in progress, and there
were small number of reconnect attempts, so all requests are
waiting for the connection.
connecting-nowait: reconnecting is in progress, there were a lot of
attempts of reconnect, all requests will return errors.
two old modes are used too:
connected: normal state
quit: exiting after fatal error or on close
Possible transitions are:
* -> quit
connecting-* -> connected
connecting-wait -> connecting-nowait (transition is done after
reconnect-delay seconds in connecting-wait mode)
connected -> connecting-wait
2. Implement reconnect in connection_co. So, in connecting-* mode,
connection_co, tries to reconnect unlimited times.
3. Retry nbd queries on channel error, if we are in connecting-wait
state.
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.
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.
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.
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.
* 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
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.
"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.
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.
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).
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.
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.
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.
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."
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."
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.
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
* 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
* 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)
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().
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.
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.
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.
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.
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.
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.
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.
projects / qemu.git / log