When running device-introspect-test, a memory leak occurred in the mos6522_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
#0 0xfffd5fe9e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffd5f7b6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaae50303d0c in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaae50303d0c in timer_new qemu/include/qemu/timer.h:544
#4 0xaaae50303d0c in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaae50303d0c in mos6522_init qemu/hw/misc/mos6522.c:490
#6 0xaaae50b77d70 in object_init_with_type qemu/qom/object.c:371
#7 0xaaae50b7ae84 in object_initialize_with_type qemu/qom/object.c:515
#8 0xaaae50b7b0f8 in object_new_with_type qemu/qom/object.c:729
#9 0xaaae50bb6d58 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#10 0xaaae50d7e1dc in qmp_marshal_device_list_properties qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaae50dc87a0 in do_qmp_dispatch_bh qemu/qapi/qmp-dispatch.c:110
#12 0xaaae50d931a0 in aio_bh_call qemu/util/async.c:136
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210112112705.380534-3-ganqixin@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
When running device-introspect-test, a memory leak occurred in the pl031_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544
#4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194
#6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515
#7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729
#8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
#12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210112112705.380534-2-ganqixin@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
No matter whether the pxb is enabled or not, the CONFIG_PXB macro in test
would keep undefined. And since pxb is now enabled for ARM Virt machine
by default, let's enable pxb unit-test by removing the CONFIG_PXB.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-8-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
PXB is now supported on ARM, so let's compile for arm_virt machine.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-7-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Exclude the resources of extra root bridges from PCI0's _CRS. Otherwise,
the resource windows would overlap in guest, and the IO resource window
would fail to be registered.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-6-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There may be some differences in pci resource assignment between guest os
and firmware.
Eg. A Bridge with Bus [d2]
-+-[0000:d2]---01.0-[d3]----01.0
where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256]
[d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K]
BAR4 (mem, 64-bit, pref) [size=64M]
In EDK2, the Resource Map would be:
PciBus: Resource Map for Bridge [D2|01|00]
Type = PMem64; Base = 0x8004000000; Length = 0x4100000; Alignment = 0x3FFFFFF
Base = 0x8004000000; Length = 0x4000000; Alignment = 0x3FFFFFF; Owner = PCI [D3|01|00:20]
Base = 0x8008000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [D3|01|00:10]
Type = Mem64; Base = 0x8008100000; Length = 0x100; Alignment = 0xFFF
It would use 0x4100000 to calculate the root bus's PMem64 resource window.
While in Linux, kernel will use 0x1FFFFFF as the alignment to calculate
the PMem64 size, which would be 0x6000000. So kernel would try to
allocate 0x6000000 from the PMem64 resource window, but since the window
size is 0x4100000 as assigned by EDK2, the allocation would fail.
The diffences could result in resource assignment failure.
Using _DSM #5 method to inform guest os not to ignore the PCI configuration
that firmware has done at boot time could handle the differences.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-5-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
AML needs Address Translation offset to describe how a bridge translates
addresses accross the bridge when using an address descriptor, and
especially on ARM, the translation offset of pio resource is usually
non zero.
Therefore, it's necessary to pass offset for pio, mmio32, mmio64 and bus
number into build_crs.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-4-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-2-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Delete spaces between function name and open parenthesis'('
Signed-off-by: Zhang Han <zhanghan64@huawei.com>
Message-id: 20210115012431.79533-1-zhanghan64@huawei.com
Message-Id: <20210115012431.79533-8-zhanghan64@huawei.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fix the line width of code.
Signed-off-by: Zhang Han <zhanghan64@huawei.com>
Message-id: 20210115012431.79533-1-zhanghan64@huawei.com
Message-Id: <20210115012431.79533-5-zhanghan64@huawei.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fix problems about braces:
-braces are necessary for all arms of if/for/while statements
-else should follow close brace '}'
Signed-off-by: Zhang Han <zhanghan64@huawei.com>
Message-id: 20210115012431.79533-1-zhanghan64@huawei.com
Message-Id: <20210115012431.79533-2-zhanghan64@huawei.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is a mismatch between message and used argument. Change
the argument from frequency to format.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-23-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rename dsound_open() to dsound_set_cooperative_level(). The
only task of that function is to set the cooperative level for
DirectSound.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-21-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
GetForegroundWindow() doesn't necessarily return the own window
handle. It just returns a handle to the currently active window
and can even return NULL. At the time dsound_open() gets called
the active window is most likely the shell window and not the
QEMU window.
Replace GetForegroundWindow() with GetDesktopWindow() which
always returns a valid window handle, and at the same time
replace the DirectSound buffer flag DSBCAPS_STICKYFOCUS with
DSBCAPS_GLOBALFOCUS where Windows only expects a valid window
handle for DirectSound function SetCooperativeLevel(). The
Microsoft online docs for IDirectSound::SetCooperativeLevel
recommend this in the remarks.
This fixes a bug where you can't hear sound from the guest.
To reproduce start qemu with -machine pcspk-audiodev=audio0
-device intel-hda -device hda-duplex,audiodev=audio0
-audiodev dsound,id=audio0,out.mixing-engine=off
from a shell and start audio playback with the hda device in the
guest. The guest will be silent. To hear guest audio you have to
activate the shell window once.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-20-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tell PulseAudio to send recorded audio data in smaller chunks
than timer_period, so there's a good chance that qemu can read
recorded audio data every time it looks for new data.
PulseAudio tries to send buffer updates at a fragsize / 2 rate.
With fragsize = timer_period / 2 * 3 the update rate is 75% of
timer_period. The lower limit for the recording buffer size
maxlength is fragsize * 2.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-19-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently with the playback buffer attribute minreq = -1 and flag
PA_STREAM_EARLY_REQUESTS PulseAudio uses minreq = tlength / 4.
To improve audio playback with larger PulseAudio server side
buffers, limit minreq to a maximum of 75% of audio timer_rate.
That way there is a good chance qemu receives a stream buffer
size update before it tries to write data to the playback stream.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-18-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The audio buffer size in audio/paaudio.c is typically larger
than expected. Just comment the bugs in qpa_init_in() and
qpa_init_out() for now. Fixing these bugs may break glitch free
audio playback with fine tuned user audio settings.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-17-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Don't call pa_stream_writable_size() in qpa_get_buffer_out()
before the playback stream is ready. This prevents a lot of the
following pulseaudio error messages.
pulseaudio: pa_stream_writable_size failed
pulseaudio: Reason: Bad state
To reproduce start qemu with
-parallel none -device gus,audiodev=audio0 -audiodev pa,id=audio0
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-15-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Don't call pa_stream_writable_size() in qpa_write() before the
playback stream is ready. This prevents a lot of the following
pulseaudio error messages.
pulseaudio: pa_stream_writable_size failed
pulseaudio: Reason: Bad state
To reproduce start qemu with
-parallel none -device gus,audiodev=audio0
-audiodev pa,id=audio0,out.mixing-engine=off
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-14-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The pulseaudio backend currently converts, clips and copies audio
playback samples in the mixing-engine sample buffer multiple
times.
In qpa_get_buffer_out() the function pa_stream_begin_write()
returns a rather large buffer and this allows audio_pcm_hw_run_out()
in audio/audio.c to copy all samples in the mixing-engine buffer
to the pulse audio buffer. Immediately after copying, qpa_write()
notices with a call to pa_stream_writable_size() that pulse audio
only needs a smaller part of the copied samples and ignores the
rest. This copy and ignore process happens several times for each
audio sample.
To fix this behaviour, call pa_stream_writable_size() in
qpa_get_buffer_out() to limit the number of samples
audio_pcm_hw_run_out() will convert. With this change the
pulseaudio pcm_ops functions put_buffer_out and write are no
longer identical and a separate qpa_put_buffer_out is needed.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-13-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Break the unnecessary dependency of the generic buffer management
code on mixing-engine. This is required for the next patch.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-10-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add audio recording functions. SDL 2.0.5 or later is required to
use the recording functions. Playback continues to work with
earlier SDL 2.0 versions.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-9-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Split off pcm_ops function run_buffer_in from get_buffer_in and
call run_buffer_in before get_buffer_in.
The next patch only needs the generic buffer management part
from audio_generic_get_buffer_in().
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-8-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
With the modern audio functions it's possible to add new
features like audio recording.
As a side effect this patch fixes a bug where SDL2 can't be used
on Windows. This bug was reported on the qemu-devel mailing list at
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg04043.html
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-7-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fill the remaining sample buffer with silence. To fill it with
zeroes is wrong for unsigned samples because this is silence
with a DC bias.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-6-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Always fill the remaining audio callback buffer with silence.
SDL 2.0 doesn't initialize the audio callback buffer. This was
an incompatible change compared to SDL 1.2. For reference read
the SDL 1.2 to 2.0 migration guide.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-5-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Every emulated audio device has a way to enable audio playback. Don't
start playback until the guest enables the audio device. This patch
keeps the SDL2 device pause state in sync with hw->enabled.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-4-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently there is a crackling noise with SDL2 audio playback.
Commit bcf19777df: "audio/sdlaudio: Allow audio playback with
SDL2" already mentioned the crackling noise.
Add an out.buffer-count option to give users a chance to select
sane settings for glitch free audio playback. The idea was taken
from the coreaudio backend.
The in.buffer-count option will be used with one of the next
patches.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-id: 9315afe5-5958-c0b4-ea1e-14769511a9d5@t-online.de
Message-Id: <20210110100239.27588-3-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The extended desktop resize encoding adds support for (a) clients
sending resize requests to the server, and (b) multihead support.
This patch implements (a). All resize requests are rejected by qemu.
Qemu can't resize the framebuffer on its own, this is in the hands of
the guest, so all qemu can do is forward the request to the guest.
Should the guest actually resize the framebuffer we can notify the vnc
client later with a separate message.
This requires support in the display device. Works with virtio-gpu.
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#extendeddesktopsize-pseudo-encoding
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20210112134120.2031837-4-kraxel@redhat.com
qemu sends various state info like current cursor shape to newly connected
clients in response to a set_encoding message. This is not correct according
to the rfb spec. Send that information in response to a full (incremental=0)
framebuffer update request instead. Also send the resize information
unconditionally, not only in case of an actual server-side change.
This makes the qemu vnc server conform to the spec and allows clients to
request the complete vnc server state without reconnect.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20210112134120.2031837-3-kraxel@redhat.com
Move the check whenever a cursor exists into the vnc_cursor_define()
function so callers don't have to do it.
Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20210112134120.2031837-2-kraxel@redhat.com
