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
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
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
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
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
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: b01422622b
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
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>
The 32-bit product should be sign-extended, not zero-extended.
Fixes: ea96b37464
Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20190912183058.17947-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The need for specifying "-hda" together with "-kernel" has been removed in
commit 57a46d0579 ("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>
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: b6805e127c ("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>
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: bc725e6515 ("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>
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: 48390a7c27 ("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.
Fixes: 1ee2d7ba72 ("s390x/tcg: Implement VECTOR SUBTRACT COMPUTE BORROW INDICATION")
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-5-david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We forgot to propagate the highest bit accross the high doubleword in
two cases (shift >=64).
Fixes: 5f724887e3 ("s390x/tcg: Implement VECTOR SHIFT RIGHT ARITHMETIC")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-4-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We missed that we always read a "double-wide even-odd element
pair of the fourth operand". Fix it in all four variants.
Fixes: 1b430aec41 ("s390x/tcg: Implement VECTOR MULTIPLY AND ADD *")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-3-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We have to read from odd offsets.
Fixes: 2bf3ee38f1 ("s390x/tcg: Implement VECTOR MULTIPLY *")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191021085715.3797-2-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
No need to double-check if we have a write.
Found by Coverity (CID: 1406404).
Fixes: 31b5941906 ("target/s390x: Return exception from mmu_translate_real")
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191017121922.18840-1-david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
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>
If the format is not the syscall last argument, a comma is append.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20191021114857.20538-9-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Extract common print_sockfd() from various socket related syscalls.
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20191021114857.20538-7-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
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.
Signed-off-by: Shu-Chun Weng <scw@google.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20191018001920.178283-1-scw@google.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
audio: 5.1/7.1 support for alsa, pa and usb-audio.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJdqWymAAoJEEy22O7T6HE4xkwP/RMd2YrNeTpeBHOII6DF/o0S
AFY7V8L1sEsvjBpEGwcOWs5Jf9ByRbxkq41w6g5RqzKIHp5kT5dtlRQ1oc4Efg+x
AK/UGbyNTyp2hmQY6FO6MDMgq8ZgqNaBLvlTr6ZxxIrIoKUWN3jE3wwjnQsuDSv7
RcD8L891km4W4yxhpAVsT2a/6yOAsqKR0h3lgVWvsF+ugsIa3Ip72FehCL95VbGs
TbdyWIv75ibkZXIZxTIQjxAEHrv9tkQU8slSNFZKZDamCSrlPyVQBfaHksV+4DQV
SWana1NB1xu2ZLsBcbDnsWWqsBtK0zWmzJ6Y+Gurfsq2981BAP8yw0xZ90g3bFFB
vaDcDly+b/4v7UNLKtl2ArzC3vjQS4djuOExgs5s6rcmWfYHw9fYor4MzIvTDnD3
KkPUrmxOCKD8MtL5XAXadxUS9GK3A5MD1UOIoe8WI/cNQAZhWLM1ofEh//341VAP
tvkQfCF4mqW/1Rz+p6Vp0Ra3FG5+wVXTL9M8yW6ztD7GPUaw9ANoSXk9xTJa5EY5
760l5WrNVdFMQxxl+M82aI3/GT3O/bE3Gz5FCjf7JoigIZKG6gKphNFxJySsypxV
xXoMmE+6P4VoT3g7FfJ5yf9rksCt6Pn5ryx//AQPSuyGF21vF/zNfH98XycXf6ma
H5JDtM9kEphMQrLxE5LN
=pQ+6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kraxel/tags/audio-20191018-pull-request' into staging
audio: bugfixes, pa connection and stream naming.
audio: 5.1/7.1 support for alsa, pa and usb-audio.
# gpg: Signature made Fri 18 Oct 2019 08:41:26 BST
# gpg: using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138
* 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>
If we try to start QEMU with "-k en-us", qemu prints a message and exits
with:
qemu-system-i386: could not read keymap file: 'en-us'
It's because this function is called way too early, before
qemu_add_data_dir() is called, and so qemu_find_file() fails.
To fix that, move init_keyboard_layout() from the class init function to the
instance init function.
Reported-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-id: 20190923220658.27007-1-laurent@vivier.eu
Fixes: 6105683da3 ("ui: add an embedded Barrier client")
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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>
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>
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.
Buglink: https://bugs.launchpad.net/qemu/+bug/1847906
Signed-off-by: Hikaru Nishida <hikarupsp@gmail.com>
Message-id: 20191015010734.85229-1-hikarupsp@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: ff866985ed369f1e18ea7c70da6a7fce8e241deb.1570996490.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: 98e96606228afa907fa238eac26573d5af63434a.1570996490.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Which currently only means removing some checks. Old code won't require
more than two channels, but new code will need it.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: 7e53be1f97e939ed3bb729ef39e76b775643118a.1570996490.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: 1351fd9bcce0ff20d81850c5292722194329de02.1570996490.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: 5765186a7aadd51a72bc7d3e804307f0ee8a34ce.1570996490.git.DirtY.iCE.hu@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
