Peter Maydell [Fri, 14 Jan 2022 15:56:30 +0000 (15:56 +0000)]
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches
- qemu-storage-daemon: Add vhost-user-blk help
- block-backend: Fix use-after-free for BDS pointers after aio_poll()
- qemu-img: Fix sparseness of output image with unaligned ranges
- vvfat: Fix crashes in read-write mode
- Fix device deletion events with -device JSON syntax
- Code cleanups
# gpg: Signature made Fri 14 Jan 2022 13:50:16 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream:
iotests/testrunner.py: refactor test_field_width
block: drop BLK_PERM_GRAPH_MOD
qemu-img: make is_allocated_sectors() more efficient
iotests: Test qemu-img convert of zeroed data cluster
vvfat: Fix vvfat_write() for writes before the root directory
vvfat: Fix size of temporary qcow file
iotests/308: Fix for CAP_DAC_OVERRIDE
iotests/stream-error-on-reset: New test
block-backend: prevent dangling BDS pointers across aio_poll()
qapi/block: Restrict vhost-user-blk to CONFIG_VHOST_USER_BLK_SERVER
qemu-storage-daemon: Add vhost-user-blk help
docs: Correct 'vhost-user-blk' spelling
softmmu: fix device deletion events with -device JSON syntax
include/sysemu/blockdev.h: remove drive_get_max_devs
include/sysemu/blockdev.h: remove drive_mark_claimed_by_board and inline drive_def
block_int: make bdrv_backing_overridden static
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/kraxel/tags/kraxel-20220114-pull-request:
ui/input-legacy: pass horizontal scroll information
ui/sdl2: pass horizontal scroll information to the device code
ui/gtk: pass horizontal scroll information to the device code
ui/cocoa: pass horizontal scroll information to the device code
ps2: Initial horizontal scroll support
edid: Added support for 4k@60 Hz monitor
edid: set default resolution to 1280x800 (WXGA)
hw/mips/jazz: Inline vga_mmio_init() and remove it
hw/display/vga-mmio: QOM'ify vga_mmio_init() as TYPE_VGA_MMIO
hw/display/vga-mmio: Inline vga_mm_init()
hw/display: Rename VGA_ISA_MM -> VGA_MMIO
uas: add missing return
ui: fix gtk clipboard clear assertion
ui/dbus: fix buffer-overflow detected by ASAN
hw/audio/intel-hda: fix stream reset
dsoundaudio: fix crackling audio recordings
jackaudio: use ifdefs to hide unavailable functions
ui/vnc.c: Fixed a deadlock bug.
usb: allow max 8192 bytes for desc
hw/usb/dev-wacom: add missing HID descriptor
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A lot of Optional[] types doesn't make code beautiful.
test_field_width defaults to 8, but that is never used in the code.
More over, if we want some default behavior for single call of
test_run(), it should just print the whole test name, not limiting or
expanding its width, so 8 is bad default.
So, just drop the default as unused for now.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211210201450.101576-1-vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
First, this permission never protected a node from being changed, as
generic child-replacing functions don't check it.
Second, it's a strange thing: it presents a permission of parent node
to change its child. But generally, children are replaced by different
mechanisms, like jobs or qmp commands, not by nodes.
Graph-mod permission is hard to understand. All other permissions
describe operations which done by parent node on its child: read,
write, resize. Graph modification operations are something completely
different.
The only place where BLK_PERM_GRAPH_MOD is used as "perm" (not shared
perm) is mirror_start_job, for s->target. Still modern code should use
bdrv_freeze_backing_chain() to protect from graph modification, if we
don't do it somewhere it may be considered as a bug. So, it's a bit
risky to drop GRAPH_MOD, and analyzing of possible loss of protection
is hard. But one day we should do it, let's do it now.
One more bit of information is that locking the corresponding byte in
file-posix doesn't make sense at all.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20210902093754.2352-1-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qemu-img: make is_allocated_sectors() more efficient
Consider the case when the whole buffer is zero and end is unaligned.
If i <= tail, we return 1 and do one unaligned WRITE, RMW happens.
If i > tail, we do on aligned WRITE_ZERO (or skip if target is zeroed)
and again one unaligned WRITE, RMW happens.
Let's do better: don't fragment the whole-zero buffer and report it as
ZERO: in case of zeroed target we just do nothing and avoid RMW. If
target is not zeroes, one unaligned WRITE_ZERO should not be much worse
than one unaligned WRITE.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211217164654.1184218-3-vsementsov@virtuozzo.com> Tested-by: Peter Lieven <pl@kamp.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Fri, 17 Dec 2021 16:46:53 +0000 (17:46 +0100)]
iotests: Test qemu-img convert of zeroed data cluster
This demonstrates what happens when the block status changes in
sub-min_sparse granularity, but all of the parts are zeroed out. The
alignment logic in is_allocated_sectors() prevents that the target image
remains fully sparse as expected, but turns it into a data cluster of
explicit zeros.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211217164654.1184218-2-vsementsov@virtuozzo.com> Tested-by: Peter Lieven <pl@kamp.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Thu, 9 Dec 2021 15:22:31 +0000 (16:22 +0100)]
vvfat: Fix vvfat_write() for writes before the root directory
The calculation in sector2cluster() is done relative to the offset of
the root directory. Any writes to blocks before the start of the root
directory (in particular, writes to the FAT) result in negative values,
which are not handled correctly in vvfat_write().
This changes sector2cluster() to return a signed value, and makes sure
that vvfat_write() doesn't try to find mappings for negative cluster
number. It clarifies the code in vvfat_write() to make it more obvious
that the cluster numbers can be negative.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211209152231.23756-1-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Thu, 9 Dec 2021 15:18:15 +0000 (16:18 +0100)]
vvfat: Fix size of temporary qcow file
The size of the qcow size was calculated so that only the FAT partition
would fit on it, but not the whole disk. However, offsets relative to
the whole disk are used to access it, so increase its size to be large
enough for that.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211209151815.23495-1-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Reitz [Mon, 3 Jan 2022 12:00:14 +0000 (13:00 +0100)]
iotests/308: Fix for CAP_DAC_OVERRIDE
With CAP_DAC_OVERRIDE (which e.g. root generally has), permission checks
will be bypassed when opening files.
308 in one instance tries to open a read-only file (FUSE export) with
qemu-io as read/write, and expects this to fail. However, when running
it as root, opening will succeed (thanks to CAP_DAC_OVERRIDE) and only
the actual write operation will fail.
Note this as "Case not run", but have the test pass in either case.
Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Fixes: 2c7dd057aa7bd7a875e9b1a53975c220d6380bc4
("export/fuse: Pass default_permissions for mount") Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220103120014.13061-1-hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Reitz [Tue, 11 Jan 2022 15:36:13 +0000 (15:36 +0000)]
iotests/stream-error-on-reset: New test
Test the following scenario:
- Simple stream block in two-layer backing chain (base and top)
- The job is drained via blk_drain(), then an error occurs while the job
settles the ongoing request
- And so the job completes while in blk_drain()
This was reported as a segfault, but is fixed by "block-backend: prevent
dangling BDS pointers across aio_poll()".
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2036178 Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220111153613.25453-3-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Tue, 11 Jan 2022 15:36:12 +0000 (15:36 +0000)]
block-backend: prevent dangling BDS pointers across aio_poll()
The BlockBackend root child can change when aio_poll() is invoked. This
happens when a temporary filter node is removed upon blockjob
completion, for example.
Functions in block/block-backend.c must be aware of this when using a
blk_bs() pointer across aio_poll() because the BlockDriverState refcnt
may reach 0, resulting in a stale pointer.
One example is scsi_device_purge_requests(), which calls blk_drain() to
wait for in-flight requests to cancel. If the backup blockjob is active,
then the BlockBackend root child is a temporary filter BDS owned by the
blockjob. The blockjob can complete during bdrv_drained_begin() and the
last reference to the BDS is released when the temporary filter node is
removed. This results in a use-after-free when blk_drain() calls
bdrv_drained_end(bs) on the dangling pointer.
Explicitly hold a reference to bs across block APIs that invoke
aio_poll().
Restrict vhost-user-blk in BlockExportType when
CONFIG_VHOST_USER_BLK_SERVER is disabled, so it
doesn't end listed by query-qmp-schema.
Fixes: 90fc91d50b7 ("convert vhost-user-blk server to block export API") Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-4-f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
$ qemu-storage-daemon -h
...
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
addr.type=unix,addr.path=<socket-path>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over UNIX domain socket
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
fd,addr.str=<fd>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over file descriptor
...
Fixes: 90fc91d50b7 ("convert vhost-user-blk server to block export API") Reported-by: Qing Wang <qinwang@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-3-f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reported-by: Eric Blake <eblake@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-2-f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
softmmu: fix device deletion events with -device JSON syntax
The -device JSON syntax impl leaks a reference on the created
DeviceState instance. As a result when you hot-unplug the
device, the device_finalize method won't be called and thus
it will fail to emit the required DEVICE_DELETED event.
A 'json-cli' feature was previously added against the
'device_add' QMP command QAPI schema to indicated to mgmt
apps that -device supported JSON syntax. Given the hotplug
bug that feature flag is not usable for its purpose, so
we add a new 'json-cli-hotplug' feature to indicate the
-device supports JSON without breaking hotplug.
Fixes: 5dacda5167560b3af8eadbce5814f60ba44b467e
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/802 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220105123847.4047954-2-berrange@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Tested-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Remove drive_get_max_devs, as it is not used by anyone.
Last use was removed in commit 8f2d75e81d5
("hw: Drop superfluous special checks for orphaned -drive").
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20211215121140.456939-4-eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
include/sysemu/blockdev.h: remove drive_mark_claimed_by_board and inline drive_def
drive_def is only a particular use case of
qemu_opts_parse_noisily, so it can be inlined.
Also remove drive_mark_claimed_by_board, as it is only defined
but not implemented (nor used) anywhere.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20211215121140.456939-3-eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
bdrv_backing_overridden is only used in block.c, so there is
no need to leave it in block_int.h
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20211215121140.456939-2-eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Maydell [Fri, 14 Jan 2022 10:43:32 +0000 (10:43 +0000)]
Merge remote-tracking branch 'remotes/stefanha-gitlab/tags/block-pull-request' into staging
Pull request
# gpg: Signature made Wed 12 Jan 2022 17:13:54 GMT
# gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8
* remotes/stefanha-gitlab/tags/block-pull-request:
virtio: unify dataplane and non-dataplane ->handle_output()
virtio: use ->handle_output() instead of ->handle_aio_output()
virtio-scsi: prepare virtio_scsi_handle_cmd for dataplane
virtio-blk: drop unused virtio_blk_handle_vq() return value
virtio: get rid of VirtIOHandleAIOOutput
aio-posix: split poll check from ready handler
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Dmitry Petrov [Sat, 8 Jan 2022 15:39:47 +0000 (16:39 +0100)]
ui/input-legacy: pass horizontal scroll information
This code seems to be used by vmport hack, passing these values allows
to implement horizontal scroll support even when using vmport.
In case it's not supported horizontal scroll will act as a vertical one.
Dmitry Petrov [Sat, 8 Jan 2022 15:39:43 +0000 (16:39 +0100)]
ps2: Initial horizontal scroll support
This change adds support for horizontal scroll to ps/2 mouse device
code. The code is implemented to match the logic of linux kernel
which is used as a reference.
* remotes/bonzini-gitlab/tags/for-upstream:
meson: reenable filemonitor-inotify compilation
meson: build all modules by default
configure: do not create roms/seabios/config.mak if SeaBIOS not present
tests/tcg: Fix target-specific Makefile variables path for user-mode
KVM: x86: ignore interrupt_bitmap field of KVM_GET/SET_SREGS
KVM: use KVM_{GET|SET}_SREGS2 when supported.
meson: add comments in the target-specific flags section
configure, meson: move config-poison.h to meson
meson: build contrib/ executables after generated headers
configure: move non-command-line variables away from command-line parsing section
configure: parse --enable/--disable-strip automatically, flip default
configure, makefile: remove traces of really old files
configure: do not set bsd_user/linux_user early
configure: simplify creation of plugin symbol list
block/file-posix: Simplify the XFS_IOC_DIOINFO handling
meson: cleanup common-user/ build
user: move common-user includes to a subdirectory of {bsd,linux}-user/
meson: reuse common_user_inc when building files specific to user-mode emulators
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Thu, 13 Jan 2022 11:18:24 +0000 (11:18 +0000)]
Merge remote-tracking branch 'remotes/legoater/tags/pull-ppc-20220112' into staging
ppc 7.0 queue:
* New SLOF for PPC970 and POWER5+ (Alexey)
* Fixes for POWER5+ pseries (Cedric)
* Updates of documentation (Leonardo and Thomas)
* First step of exception model cleanup (Fabiano)
* User created PHB3/PHB4 devices (Daniel and Cedric)
# gpg: Signature made Wed 12 Jan 2022 10:43:21 GMT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/legoater/tags/pull-ppc-20220112: (34 commits)
ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()
ppc/pnv: turn pnv_phb4_update_regions() into static
ppc/pnv: Introduce user creatable pnv-phb4 devices
ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack
ppc/pnv: move PHB4 XSCOM init to phb4_realize()
ppc/pnv: set phb4 properties in stk_realize()
pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()
pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS name
pnv_phb3.h: change TYPE_PNV_PHB3_ROOT_BUS name
ppc/pnv: Move num_phbs under Pnv8Chip
ppc/pnv: Complete user created PHB3 devices
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
ppc/pnv: Introduce support for user created PHB3 devices
pnv_phb4.c: check if root port exists in rc_config functions
pnv_phb4.c: make pnv-phb4-root-port user creatable
ppc/pnv: Attach PHB3 root port device when defaults are enabled
pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_port
pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_port
target/ppc: Set the correct endianness for powernv memory dumps
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Satyeshwar Singh [Tue, 16 Nov 2021 22:11:03 +0000 (14:11 -0800)]
edid: Added support for 4k@60 Hz monitor
Previously, the large modes (>1080p) that were generated by Qemu in its EDID
were all 50 Hz. If we provide them to a Guest OS and the user selects
one of these modes, then the OS by default only gets 50 FPS. This is
especially true for Windows OS. With this patch, we are now exposing a
3840x2160@60 Hz which will allow the guest OS to get 60 FPS.
Currently QEMU defaults to a resolution of 1024x768 when exposing EDID
info to the guest OS. The EDID default info is important as this will
influence what resolution many guest OS will configure the screen with
on boot. It can also potentially influence what resolution the firmware
will configure the screen with, though until very recently EDK2 would
not handle EDID info.
One important thing to bear in mind is that the default graphics card
driver provided by Windows will leave the display set to whatever
resolution was enabled by the firmware on boot. Even if sufficient
VRAM is available, the resolution can't be changed without installing
new drivers. IOW, the default resolution choice is quite important
for usability of Windows.
Modern real world monitor hardware for desktop/laptop has supported
resolutions higher than 1024x768 for a long time now, perhaps as long
as 15+ years. There are quite a wide variety of native resolutions in
use today, however, and in wide screen form factors the height may not
be all that tall.
None the less, it is considered that there is scope for making the
QEMU default resolution slightly larger.
In considering what possible new default could be suitable, choices
considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA).
In many ways, vertical space is the most important, and so 720p was
discarded due to loosing vertical space, despite being 25% wider.
The SXGA resolution would be good, but when taking into account
window titlebars/toolbars and window manager desktop UI, this might
be a little too tall for some users to fit the guest on their physical
montior.
This patch thus suggests a modest change to 1280x800 (WXGA). This
only consumes 1 MB per colour channel, allowing double buffered
framebuffer in 8 MB of VRAM. Width wise this is 25% larger than
QEMU's current default, but height wise this only adds 5%, so the
difference isn't massive on the QEMU side.
Overall there doesn't appear to be a compelling reason to stick
with 1024x768 resolution.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20211129140508.1745130-1-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When closing the QEMU Gtk display window, it can occasionaly warn:
qemu-system-x86_64: Gtk: gtk_clipboard_set_with_data: assertion 'targets != NULL' failed
#3 0x00007ffff4f02f22 in gtk_clipboard_set_with_data (clipboard=<optimized out>, targets=<optimized out>, n_targets=<optimized out>, get_func=<optimized out>, clear_func=<optimized out>, user_data=<optimized out>) at /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtkclipboard.c:672
#4 0x00007ffff552cd75 in gd_clipboard_update_info (gd=0x5555579a9e00, info=0x555557ba4b50) at ../ui/gtk-clipboard.c:98
#5 0x00007ffff552ce00 in gd_clipboard_notify (notifier=0x5555579aaba8, data=0x7fffffffd720) at ../ui/gtk-clipboard.c:128
#6 0x000055555603e0ff in notifier_list_notify (list=0x555556657470 <clipboard_notifiers>, data=0x7fffffffd720) at ../util/notify.c:39
#7 0x000055555594e8e0 in qemu_clipboard_update (info=0x555557ba4b50) at ../ui/clipboard.c:54
#8 0x000055555594e840 in qemu_clipboard_peer_release (peer=0x55555684a5b0, selection=QEMU_CLIPBOARD_SELECTION_PRIMARY) at ../ui/clipboard.c:40
#9 0x000055555594e786 in qemu_clipboard_peer_unregister (peer=0x55555684a5b0) at ../ui/clipboard.c:19
#10 0x000055555595f044 in vdagent_disconnect (vd=0x55555684a400) at ../ui/vdagent.c:852
#11 0x000055555595f262 in vdagent_chr_fini (obj=0x55555684a400) at ../ui/vdagent.c:908
==441487==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000025a70 at pc 0x7f0817bb764c bp 0x7ffde672ae60 sp 0x7ffde672ae58
WRITE of size 8 at 0x611000025a70 thread T0
#0 0x7f0817bb764b in dbus_vc_class_init ../ui/dbus.c:401
Volker Rümelin [Sun, 26 Dec 2021 15:40:17 +0000 (16:40 +0100)]
hw/audio/intel-hda: fix stream reset
Quote from:
High Definition Audio Specification 1.0a, section 3.3.35
Offset 80: {IOB}SDnCTL Stream Reset (SRST): Writing a 1 causes
the corresponding stream to be reset. The Stream Descriptor
registers (except the SRST bit itself) ... are reset.
Change the code to reset the Stream Descriptor Control and Status
registers except the SRST bit.
Volker Rümelin [Sun, 26 Dec 2021 15:40:15 +0000 (16:40 +0100)]
jackaudio: use ifdefs to hide unavailable functions
On Windows the jack_set_thread_creator() function and on MacOS the
pthread_setname_np() function with a thread pointer paramater is
not available. Use #ifdefs to remove the jack_set_thread_creator()
function call and the qjack_thread_creator() function in both
cases.
The qjack_thread_creator() function just sets the name of the
created thread for debugging purposes and isn't really necessary.
From the jack_set_thread_creator() documentation:
(...)
No normal application/client should consider calling this. (...)
Rao Lei [Wed, 5 Jan 2022 02:08:08 +0000 (10:08 +0800)]
ui/vnc.c: Fixed a deadlock bug.
The GDB statck is as follows:
(gdb) bt
0 __lll_lock_wait (futex=futex@entry=0x56211df20360, private=0) at lowlevellock.c:52
1 0x00007f263caf20a3 in __GI___pthread_mutex_lock (mutex=0x56211df20360) at ../nptl/pthread_mutex_lock.c:80
2 0x000056211a757364 in qemu_mutex_lock_impl (mutex=0x56211df20360, file=0x56211a804857 "../ui/vnc-jobs.h", line=60)
at ../util/qemu-thread-posix.c:80
3 0x000056211a0ef8c7 in vnc_lock_output (vs=0x56211df14200) at ../ui/vnc-jobs.h:60
4 0x000056211a0efcb7 in vnc_clipboard_send (vs=0x56211df14200, count=1, dwords=0x7ffdf1701338) at ../ui/vnc-clipboard.c:138
5 0x000056211a0f0129 in vnc_clipboard_notify (notifier=0x56211df244c8, data=0x56211dd1bbf0) at ../ui/vnc-clipboard.c:209
6 0x000056211a75dde8 in notifier_list_notify (list=0x56211afa17d0 <clipboard_notifiers>, data=0x56211dd1bbf0) at ../util/notify.c:39
7 0x000056211a0bf0e6 in qemu_clipboard_update (info=0x56211dd1bbf0) at ../ui/clipboard.c:50
8 0x000056211a0bf05d in qemu_clipboard_peer_release (peer=0x56211df244c0, selection=QEMU_CLIPBOARD_SELECTION_CLIPBOARD)
at ../ui/clipboard.c:41
9 0x000056211a0bef9b in qemu_clipboard_peer_unregister (peer=0x56211df244c0) at ../ui/clipboard.c:19
10 0x000056211a0d45f3 in vnc_disconnect_finish (vs=0x56211df14200) at ../ui/vnc.c:1358
11 0x000056211a0d4c9d in vnc_client_read (vs=0x56211df14200) at ../ui/vnc.c:1611
12 0x000056211a0d4df8 in vnc_client_io (ioc=0x56211ce70690, condition=G_IO_IN, opaque=0x56211df14200) at ../ui/vnc.c:1649
13 0x000056211a5b976c in qio_channel_fd_source_dispatch
(source=0x56211ce50a00, callback=0x56211a0d4d71 <vnc_client_io>, user_data=0x56211df14200) at ../io/channel-watch.c:84
14 0x00007f263ccede8e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
15 0x000056211a77d4a1 in glib_pollfds_poll () at ../util/main-loop.c:232
16 0x000056211a77d51f in os_host_main_loop_wait (timeout=958545) at ../util/main-loop.c:255
17 0x000056211a77d630 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531
18 0x000056211a45bc8e in qemu_main_loop () at ../softmmu/runstate.c:726
19 0x000056211a0b45fa in main (argc=69, argv=0x7ffdf1701778, envp=0x7ffdf17019a8) at ../softmmu/main.c:50
From the call trace, we can see it is a deadlock bug.
vnc_disconnect_finish will acquire the output_mutex.
But, the output_mutex will be acquired again in vnc_clipboard_send.
Repeated locking will cause deadlock. So, I move
qemu_clipboard_peer_unregister() behind vnc_unlock_output();
zhenwei pi [Wed, 12 Jan 2022 01:58:35 +0000 (09:58 +0800)]
usb: allow max 8192 bytes for desc
A device of USB video class usually uses larger desc structure, so
use larger buffer to avoid failure. (dev-video.c is ready)
This is an unlikely code path:
1, during guest startup, guest tries to probe device.
2, run 'lsusb' command in guest(or other similar commands).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Message-Id: <20220112015835.900619-1-pizhenwei@bytedance.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Dario Binacchi [Wed, 12 Jan 2022 09:01:25 +0000 (10:01 +0100)]
hw/usb/dev-wacom: add missing HID descriptor
Linux need to fill up the HID descriptor in order to let the driver be
emulated. The descriptor was downloaded from [1]. The patch was tested
with evtest tool on top of qemu 5.2.0 with linux kernel 4.19.208.
Stefan Hajnoczi [Tue, 7 Dec 2021 13:23:35 +0000 (13:23 +0000)]
virtio: use ->handle_output() instead of ->handle_aio_output()
The difference between ->handle_output() and ->handle_aio_output() was
that ->handle_aio_output() returned a bool return value indicating
progress. This was needed by the old polling API but now that the bool
return value is gone, the two functions can be unified.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-6-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 7 Dec 2021 13:23:34 +0000 (13:23 +0000)]
virtio-scsi: prepare virtio_scsi_handle_cmd for dataplane
Prepare virtio_scsi_handle_cmd() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-5-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 7 Dec 2021 13:23:33 +0000 (13:23 +0000)]
virtio-blk: drop unused virtio_blk_handle_vq() return value
The return value of virtio_blk_handle_vq() is no longer used. Get rid of
it. This is a step towards unifying the dataplane and non-dataplane
virtqueue handler functions.
Prepare virtio_blk_handle_output() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 7 Dec 2021 13:23:32 +0000 (13:23 +0000)]
virtio: get rid of VirtIOHandleAIOOutput
The virtqueue host notifier API
virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new
buffers. AioContext previously required a bool progress return value
indicating whether an event was handled or not. This is no longer
necessary because the AioContext polling API has been split into a poll
check function and an event handler function. The event handler is only
run when we know there is work to do, so it doesn't return bool.
The VirtIOHandleAIOOutput function signature is now the same as
VirtIOHandleOutput. Get rid of the bool return value.
Further simplifications will be made for virtio-blk and virtio-scsi in
the next patch.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 7 Dec 2021 13:23:31 +0000 (13:23 +0000)]
aio-posix: split poll check from ready handler
Adaptive polling measures the execution time of the polling check plus
handlers called when a polled event becomes ready. Handlers can take a
significant amount of time, making it look like polling was running for
a long time when in fact the event handler was running for a long time.
For example, on Linux the io_submit(2) syscall invoked when a virtio-blk
device's virtqueue becomes ready can take 10s of microseconds. This
can exceed the default polling interval (32 microseconds) and cause
adaptive polling to stop polling.
By excluding the handler's execution time from the polling check we make
the adaptive polling calculation more accurate. As a result, the event
loop now stays in polling mode where previously it would have fallen
back to file descriptor monitoring.
The following data was collected with virtio-blk num-queues=2
event_idx=off using an IOThread. Before:
Notice that ppoll(2) and eventfd read(2) syscalls are eliminated because
the IOThread stays in polling mode instead of falling back to file
descriptor monitoring.
As usual, polling is not implemented on Windows so this patch ignores
the new io_poll_read() callback in aio-win32.c.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-2-stefanha@redhat.com
[Fixed up aio_set_event_notifier() calls in
tests/unit/test-fdmon-epoll.c added after this series was queued.
--Stefan]
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Volker Rümelin [Fri, 7 Jan 2022 13:35:14 +0000 (14:35 +0100)]
meson: reenable filemonitor-inotify compilation
Reenable util/filemonitor-inotify compilation. Compilation was
disabled when commit a620fbe9ac ("configure: convert compiler tests
to meson, part 5") moved CONFIG_INOTIFY1 from config-host.mak to
config-host.h.
This fixes the usb-mtp device and reenables test-util-filemonitor.
Fixes: a620fbe9ac ("configure: convert compiler tests to meson, part 5")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/800 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20220107133514.7785-1-vr_qemu@t-online.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 7 Jan 2022 12:00:44 +0000 (13:00 +0100)]
meson: build all modules by default
With more recent versions of Meson, the build.ninja file is more selective
as to what is built by default, and not building the modules results in test
failures.
Mark the modules as built-by-default and, to make the dependencies more
precise, also require them to be up-to-date before running tests.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/801 Tested-by: Li Zhang <lizhang@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 7 Jan 2022 11:40:29 +0000 (12:40 +0100)]
configure: do not create roms/seabios/config.mak if SeaBIOS not present
If roms/seabios/Makefile is not present, the configure script
is not creating the roms/seabios directory anymore (commit 5dce7b8d8c, "configure: remove DIRS", 2021-12-18); thus, creating
roms/seabios/config.mak fails.
The easiest thing to do is to not create the file, since it will not
be used.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
tests/tcg: Fix target-specific Makefile variables path for user-mode
Commit 812b31d3f91 refactor missed to update this path.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise") Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211226001541.3807919-1-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 21 Dec 2021 09:12:53 +0000 (10:12 +0100)]
KVM: x86: ignore interrupt_bitmap field of KVM_GET/SET_SREGS
This is unnecessary, because the interrupt would be retrieved and queued
anyway by KVM_GET_VCPU_EVENTS and KVM_SET_VCPU_EVENTS respectively,
and it makes the flow more similar to the one for KVM_GET/SET_SREGS2.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Always include the STRIP variable in config-host.mak (it's only used
by the s390-ccw firmware build, and it adds a default if configure
omitted it), and use meson-buildoptions.sh to turn
--enable/--disable-strip into -Dstrip.
The default is now not to strip the binaries like for almost every other
package that has a configure script.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 9 Nov 2021 09:10:41 +0000 (10:10 +0100)]
configure: do not set bsd_user/linux_user early
Similar to other optional features, leave the variables empty and compute
the actual value later. Use the existence of include or source directories
to detect whether an OS or CPU supports respectively bsd-user and linux-user.
For now, BSD user-mode emulation is buildable even on TCI-only
architectures. This probably will change once safe signals are
brought over from linux-user.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 10 Dec 2021 08:55:15 +0000 (09:55 +0100)]
configure: simplify creation of plugin symbol list
--dynamic-list is present on all supported ELF (not Windows or Darwin)
platforms, since it dates back to 2006; -exported_symbols_list is
likewise present on all supported versions of macOS. Do not bother
doing a functional test in configure.
Remove the file creation from configure as well: for Darwin, move the
the creation of the Darwin-formatted symbols to meson; for ELF, use the
file in the source path directly and switch from -Wl, to -Xlinker to
not break weird paths that include a comma.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Thomas Huth [Wed, 15 Dec 2021 12:58:24 +0000 (13:58 +0100)]
block/file-posix: Simplify the XFS_IOC_DIOINFO handling
The handling for the XFS_IOC_DIOINFO ioctl is currently quite excessive:
This is not a "real" feature like the other features that we provide with
the "--enable-xxx" and "--disable-xxx" switches for the configure script,
since this does not influence lots of code (it's only about one call to
xfsctl() in file-posix.c), so people don't gain much with the ability to
disable this with "--disable-xfsctl".
It's also unfortunate that the ioctl will be disabled on Linux in case
the user did not install the right xfsprogs-devel package before running
configure. Thus let's simplify this by providing the ioctl definition
on our own, so we can completely get rid of the header dependency and
thus the related code in the configure script.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211215125824.250091-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 21 Dec 2021 15:09:54 +0000 (16:09 +0100)]
meson: cleanup common-user/ build
It is not necessary to have a separate static_library just for common_user
files; using the one that already covers the rest of common_ss is enough
unless you need to reuse some source files between emulators and tests.
Just place common files for all user-mode emulators in common_ss,
similar to what is already done for softmmu_ss in full system emulators.
The only disadvantage is that the include_directories under bsd-user/include/
and linux-user/include/ are now enabled for all targets rather than only
user mode emulators. This however is not different from how include/sysemu/
is available when building user mode emulators.
Tested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 21 Dec 2021 15:20:32 +0000 (16:20 +0100)]
user: move common-user includes to a subdirectory of {bsd,linux}-user/
Avoid polluting the compilation of common-user/ with local include files;
making an include file available to common-user/ should be a deliberate
decision in order to keep a clear interface that can be used by both
bsd-user/ and linux-user/.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* remotes/lvivier-gitlab/tags/linux-user-for-7.0-pull-request: (30 commits)
linux-user: Implement capability prctls
linux-user: Implement PR_SET_PDEATHSIG
linux-user: Map signal number in PR_GET_PDEATHSIG
linux-user: Do not special-case NULL for PR_GET_PDEATHSIG
linux-user: Move target_struct.h generic definitions to generic/
linux-user/arm: Move target_oabi_flock64 out of target_structs.h
linux-user/xtensa: Use force_sig_fault
linux-user/sparc: Use force_sig_fault
linux-user/sh4: Use force_sig_fault
linux-user/s390x: Use force_sig_fault
linux-user/riscv: Use force_sig_fault
linux-user/ppc: Use force_sig_fault
linux-user/openrisc: Use force_sig_fault
target/mips: Extract trap code into env->error_code
target/mips: Extract break code into env->error_code
linux-user/mips: Use force_sig_fault
linux-user/mips: Improve do_break
linux-user/microblaze: Fix SIGFPE si_codes
linux-user/microblaze: Use force_sig_fault
linux-user/m68k: Use force_sig_fault
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()
pnv_pec_stk_pci_xscom_write() is pnv_pec_stk_pci_xscom_ops write
callback. It writes values into regs in the stack->nest_regs[] array.
The pnv_pec_stk_pci_xscom_read read callback, on the other hand, returns
values of the stack->pci_regs[]. In fact, at this moment, the only use
of stack->pci_regs[] is in pnv_pec_stk_pci_xscom_read(). There's no code
that is written anything in stack->pci_regs[], which is suspicious.
Considering that stack->nest_regs[] is widely used by the nested
MemoryOps pnv_pec_stk_nest_xscom_ops, in both read and write callbacks,
the conclusion is that we're writing the wrong array in
pnv_pec_stk_pci_xscom_write(). This function should write stack->pci_regs[]
instead.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220111200132.633896-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
ppc/pnv: Introduce user creatable pnv-phb4 devices
This patch introduces pnv-phb4 user creatable devices that are created
in a similar manner as pnv-phb3 devices, allowing the user to interact
with the PHBs directly instead of creating PCI Express Controllers that
will create a certain amount of PHBs per controller index.
We accomplish this by doing the following:
- add a pnv_phb4_get_stack() helper to retrieve which stack an user
created phb4 would occupy;
- when dealing with an user created pnv-phb4 (detected by checking if
phb->stack is NULL at the start of phb4_realize()), retrieve its stack
and initialize its properties as done in stk_realize();
- use 'defaults_enabled()' in stk_realize() to avoid creating and
initializing a 'stack->phb' qdev that might be overwritten by an user
created pnv-phb4 device. This process is wrapped into a new helper
called pnv_pec_stk_default_phb_realize().
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack
At this moment, stack->phb is the plain PnvPHB4 device itself instead of
a pointer to the device. This will present a problem when adding user
creatable devices because we can't deal with this struct and the
realize() callback from the user creatable device.
We can't get rid of this attribute, similar to what we did when enabling
pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs
to access stack->phb to do its job. This function is called twice in
pnv_pec_stk_update_map(), which is one of the nested xscom write
callbacks (via pnv_pec_stk_nest_xscom_write()). In fact,
pnv_pec_stk_update_map() code comment is explicit about how the order of
the unmap/map operations relates with the PHB subregions.
All of this indicates that this code is tied together in a way that we
either go on a crusade, featuring lots of refactories and redesign and
considerable pain, to decouple stack and phb mapping, or we allow stack
update_map operations to access the associated PHB as it is today even
after introducing pnv-phb4 user devices.
This patch chooses the latter. Instead of getting rid of stack->phb,
turn it into a PHB pointer. This will allow us to assign an user created
PHB to an existing stack later. In this process,
pnv_pec_stk_instance_init() is removed because stack->phb is being
initialized in stk_realize() instead.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
The 'stack->phb_regs_mr' PHB4 passthrough XSCOM initialization relies on
'stack->phb' being not NULL. Moving 'stack->phb_regs_mr' region_init()
and add_subregion() to phb4_realize() time is a natural thing to do
since it's strictly PHB related.
The remaining XSCOM initialization is also related to 'stack->phb' but
in a different manner. For instance, 'stack->nest_regs_mr'
MemoryRegionOps, 'pnv_pec_stk_nest_xscom_ops', uses
pnv_pec_stk_nest_xscom_write() as a write callback. When trying to write
the PEC_NEST_STK_BAR_EN reg, pnv_pec_stk_update_map() is called. Inside
this function, pnv_phb4_update_regions() is called twice. This function
uses 'stack->phb' to manipulate memory regions of the phb.
This is not a problem now but, when enabling user creatable phb4s, a
stack that doesn't have an associated phb (i.e. stack->phb = NULL) it
will cause a SIGINT during boot in pnv_phb4_update_regions().
All this can be avoided if all XSCOM realize is moved to phb4_realize(),
when we have certainty about the existence of 'stack->phb'. A lot of
code was moved from pnv_phb4_pec.c to pnv_phb4.c due to static constant
and variables being used but the cleaner logic is worth the trouble.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Moving all phb4 properties setup to stk_realize() keeps this logic in
a single place instead of having it scattered between stk_realize() and
pec_realize().
'phb->index' can be retrieved using stack->stack_no and
pnv_phb4_pec_get_phb_id(), deprecating the use of 'phb-id' alias that
was being used for this purpose in pec_realize().
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()
Relying on stack->phb to write the xscom DT of the PEC is something that
we won't be able to do with user creatable pnv-phb4 devices.
Hopefully, this can be done by using pnv_phb4_pec_get_phb_id(), which is
already used by pnv_pec_realize() to set the phb-id of the stack. Use
the same idea in pnv_pec_dt_xscom() to write ibm,phb-index without the
need to accessing stack->phb, since stack->phb is not granted to be !=
NULL when user creatable phbs are introduced.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220110143346.455901-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
The logic inside pnv_pec_phb_offset() will be useful in the next patch
to determine the stack that should contain a PHB4 device.
Move the function to pnv_phb4.c and make it public since there's no
pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a
parameter and make the function return 'phb-id' directly. And rename it
to pnv_phb4_pec_get_phb_id() to be even clearer about the function
intent.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220110143346.455901-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Similar to what was happening with pnv-phb3 buses,
TYPE_PNV_PHB4_ROOT_BUS set to "pnv-phb4-root-bus" is a bit too long for
a default root bus name. The usual default name for theses buses in QEMU
are 'pcie', but we want to make a distinction between pnv-phb4 buses and
other PCIE buses, at least as far as default name goes, because not all
PCIE devices are attachable to a pnv-phb4 root-bus type.
Changing the default to 'pnv-phb4-root' allow us to have a shorter name
while making this bus distinct, and the user can always set its own bus
naming via the "id" attribute anyway.
This is the 'info qtree' output after this change, using a powernv9
domain with 2 sockets and default settings enabled:
The TYPE_PNV_PHB3_ROOT_BUS name is used as the default bus name when
the dev has no 'id'. However, pnv-phb3-root-bus is a bit too long to be
used as a bus name.
Most common QEMU buses and PCI controllers are named based on their bus
type (e.g. pSeries spapr-pci-host-bridge is called 'pci'). The most
common name for a PCIE bus controller in QEMU is 'pcie'. Naming it
'pcie' would break the documented use of the pnv-phb3 device, since
'pcie.0' would now refer to the root bus instead of the first root port.
There's nothing particularly wrong with the 'root-bus' name used before,
aside from the fact that 'root-bus' is being used for pnv-phb3 and
pnv-phb4 created buses, which is not quite correct since these buses
aren't implemented the same way in QEMU - you can't plug a
pnv-phb4-root-port into a pnv-phb3 root bus, for example.
This patch renames it as 'pnv-phb3-root', which is a compromise between
the existing and the previously used name. Creating 3 phbs without ID
will result in an "info qtree" output similar to this:
bus: main-system-bus
type System
dev: pnv-phb3, id ""
index = 2 (0x2)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.2
type pnv-phb3-root
(...)
dev: pnv-phb3, id ""
index = 1 (0x1)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.1
type pnv-phb3-root
(...)
dev: pnv-phb3, id ""
index = 0 (0x0)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.0
type pnv-phb3-root
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Cédric Le Goater [Wed, 12 Jan 2022 10:28:27 +0000 (11:28 +0100)]
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
The powernv machine uses the object hierarchy to populate the device
tree and each device should be parented to the chip it belongs to.
This is not the case for user created devices which are parented to
the container "/unattached".
Make sure a PHB3 device is parented to its chip by reparenting the
object if necessary.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
pnv_phb4.c: check if root port exists in rc_config functions
pnv_phb4_rc_config_read() and pnv_phb4_rc_config_write() are asserting
the existence of the root port. The root port is now optional, and there
will be cases where a pnv-phb4 device won't have a root port attached.
Instead of asserting, check if the root port exists before read/writing
into it.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
pnv_phb4.c: make pnv-phb4-root-port user creatable
We want to create only the absolutely minimal amount of devices when
running with -nodefaults. The root port is something that the machine
can boot up without. But, to do that, we need to provide a way for the
user to add them by hand.
This patch makes pnv-phb4-root-port user creatable and then uses the
pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when
running with default settings.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
This error comes from the realize() function of its parent type,
rp_realize() from TYPE_PCIE_ROOT_PORT. pcie_chassis_add_slot() fails
with -EBUSY if there's an existing PCIESlot that has the same
chassis/slot value, regardless of being in a different bus.
One way to prevent this error is simply set chassis and slot values in
the command line. However, since phb3 root buses only supports a single
root port, we can just get an unique chassis/slot value by checking
which root bus the pnv_phb3_root_port is going to be attached, get the
equivalent phb3 device and use its chip-id and index values, which are
guaranteed to be unique.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Fabiano Rosas [Wed, 12 Jan 2022 10:28:27 +0000 (11:28 +0100)]
target/ppc: Set the correct endianness for powernv memory dumps
We use the endianness of interrupts to determine which endianness to
use for the guest kernel memory dump. For machines that support HILE
(powernv8 and up) we have been always generating big endian dump
files.
This patch uses the HILE support recently added to
ppc_interrupts_little_endian to fix the endianness of the dumps for
powernv machines.
Fabiano Rosas [Wed, 12 Jan 2022 10:28:27 +0000 (11:28 +0100)]
target/ppc: Add MSR_ILE support to ppc_interrupts_little_endian
Some CPUs set ILE via an MSR bit. We can make
ppc_interrupts_little_endian handle that case as well. Now we have a
centralized way of determining the endianness of interrupts.
This change has no functional impact.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20220107222601.4101511-6-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Fabiano Rosas [Wed, 12 Jan 2022 10:28:27 +0000 (11:28 +0100)]
target/ppc: Add HV support to ppc_interrupts_little_endian
The ppc_interrupts_little_endian function could be used for interrupts
delivered in Hypervisor mode, so add support for powernv8 and powernv9
to it.
Also drop the comment because it is inaccurate, all CPUs that can run
little endian can have interrupts in little endian. The point is
whether they can take interrupts in an endianness different from
MSR_LE.
This change has no functional impact.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20220107222601.4101511-5-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Thomas Huth [Wed, 12 Jan 2022 10:28:26 +0000 (11:28 +0100)]
MAINTAINERS: Improve the PowerPC machines section
Add some documentation files to the corresponding machine sections
and mention the machine names in the section titles where it is
not so obvious (e.g. that "taihu" is a 405 machine).
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220105104800.407570-1-thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Cédric Le Goater [Wed, 12 Jan 2022 10:28:26 +0000 (11:28 +0100)]
target/ppc: Add extra float instructions to POWER5P processors
ISA v2.03 introduced Floating Round to Integer instructions : frin,
friz, frip, and frim. Add them to POWER5+.
The PPC_FLOAT_EXT flag also includes the fre (Floating Reciprocal
Estimate) instruction which was introduced in ISA v2.0x. The
architecture document says its optional and that might be the reason
why it has been kept under the PPC_FLOAT_EXT flag. This means 970 CPUs
can not use it under QEMU, which doesn't seem to be a problem.
Cédric Le Goater [Wed, 12 Jan 2022 10:28:26 +0000 (11:28 +0100)]
spapr: Fix support of POWER5+ processors
POWER5+ (ISA v2.03) processors are supported by the pseries machine
but they do not have Altivec instructions. Do not advertise support
for it in the DT.
To be noted that this test is in contradiction with the assert in
cap_vsx_apply().
Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Fabiano Rosas <farosas@linux.ibm.com>
Message-Id: <20220105095142.3990430-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
projects / mirror_qemu.git / log