Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use qemu for arm SVE256 #19

Open
vineel96 opened this issue Oct 26, 2023 · 0 comments
Open

Use qemu for arm SVE256 #19

vineel96 opened this issue Oct 26, 2023 · 0 comments

Comments

@vineel96
Copy link

Hello,
How can we use qemu to install specifically for arm sve256 instruction set?
kheubaum pushed a commit that referenced this issue Feb 8, 2024
@kevmw
virtio: Drop out of coroutine context in virtio_load()
df33ce9 
virtio_load() as a whole should run in coroutine context because it
reads from the migration stream and we don't want this to block.

However, it calls virtio_set_features_nocheck() and devices don't
expect their .set_features callback to run in a coroutine and therefore
call functions that may not be called in coroutine context. To fix this,
drop out of coroutine context for calling virtio_set_features_nocheck().

Without this fix, the following crash was reported:

  #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
  #1  0x00007efc738c05d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
  #2  0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
  #3  0x00007efc738477f3 in __GI_abort () at abort.c:79
  #4  0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "", assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()",
     file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c", line=line@entry=275, function=function@entry=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:92
  #5  0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf "!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275,
     function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:101
  #6  0x0000560aebcd8dd6 in bdrv_register_buf ()
  #7  0x0000560aeb97ed97 in ram_block_added.llvm ()
  #8  0x0000560aebb8303f in ram_block_add.llvm ()
  #9  0x0000560aebb834fa in qemu_ram_alloc_internal.llvm ()
  #10 0x0000560aebb2ac98 in vfio_region_mmap ()
  #11 0x0000560aebb3ea0f in vfio_bars_register ()
  #12 0x0000560aebb3c628 in vfio_realize ()
  #13 0x0000560aeb90f0c2 in pci_qdev_realize ()
  #14 0x0000560aebc40305 in device_set_realized ()
  #15 0x0000560aebc48e07 in property_set_bool.llvm ()
  #16 0x0000560aebc46582 in object_property_set ()
  #17 0x0000560aebc4cd58 in object_property_set_qobject ()
  #18 0x0000560aebc46ba7 in object_property_set_bool ()
  #19 0x0000560aeb98b3ca in qdev_device_add_from_qdict ()
  #20 0x0000560aebb1fbaf in virtio_net_set_features ()
  #21 0x0000560aebb46b51 in virtio_set_features_nocheck ()
  #22 0x0000560aebb47107 in virtio_load ()
  #23 0x0000560aeb9ae7ce in vmstate_load_state ()
  #24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main ()
  #25 0x0000560aeb9d45e1 in qemu_loadvm_state ()
  #26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm ()
  #27 0x0000560aebeace56 in coroutine_trampoline.llvm ()

Cc: [email protected]
Buglink: https://issues.redhat.com/browse/RHEL-832
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 92e2e6a)
Signed-off-by: Michael Tokarev <[email protected]>
jlevon pushed a commit to jlevon/qemu that referenced this issue Dec 5, 2024
@foxmox
block/reqlist: allow adding overlapping requests
6475155 
Allow overlapping request by removing the assert that made it
impossible. There are only two callers:

1. block_copy_task_create()

It already asserts the very same condition before calling
reqlist_init_req().

2. cbw_snapshot_read_lock()

There is no need to have read requests be non-overlapping in
copy-before-write when used for snapshot-access. In fact, there was no
protection against two callers of cbw_snapshot_read_lock() calling
reqlist_init_req() with overlapping ranges and this could lead to an
assertion failure [1].

In particular, with the reproducer script below [0], two
cbw_co_snapshot_block_status() callers could race, with the second
calling reqlist_init_req() before the first one finishes and removes
its conflicting request.

[0]:

> #!/bin/bash -e
> dd if=/dev/urandom of=/tmp/disk.raw bs=1M count=1024
> ./qemu-img create /tmp/fleecing.raw -f raw 1G
> (
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev raw,node-name=node0,file.driver=file,file.filename=/tmp/disk.raw \
> --blockdev raw,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.raw \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write", "file": "node0", "target": "node1", "node-name": "node3" } }
> {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", "file": "node3", "node-name": "snap0" } }
> {"execute": "nbd-server-start", "arguments": {"addr": { "type": "unix", "data": { "path": "/tmp/nbd.socket" } } } }
> {"execute": "block-export-add", "arguments": {"id": "exp0", "node-name": "snap0", "type": "nbd", "name": "exp0"}}
> EOF
> ) &
> sleep 5
> while true; do
> ./qemu-nbd -d /dev/nbd0
> ./qemu-nbd -c /dev/nbd0 nbd:unix:/tmp/nbd.socket:exportname=exp0 -f raw -r
> nbdinfo --map 'nbd+unix:///exp0?socket=/tmp/nbd.socket'
> done

[1]:

> oracle#5  0x000071e5f0088eb2 in __GI___assert_fail (...) at ./assert/assert.c:101
> oracle#6  0x0000615285438017 in reqlist_init_req (...) at ../block/reqlist.c:23
> oracle#7  0x00006152853e2d98 in cbw_snapshot_read_lock (...) at ../block/copy-before-write.c:237
> oracle#8  0x00006152853e3068 in cbw_co_snapshot_block_status (...) at ../block/copy-before-write.c:304
> oracle#9  0x00006152853f4d22 in bdrv_co_snapshot_block_status (...) at ../block/io.c:3726
> oracle#10 0x000061528543a63e in snapshot_access_co_block_status (...) at ../block/snapshot-access.c:48
> oracle#11 0x00006152853f1a0a in bdrv_co_do_block_status (...) at ../block/io.c:2474
> oracle#12 0x00006152853f2016 in bdrv_co_common_block_status_above (...) at ../block/io.c:2652
> oracle#13 0x00006152853f22cf in bdrv_co_block_status_above (...) at ../block/io.c:2732
> oracle#14 0x00006152853d9a86 in blk_co_block_status_above (...) at ../block/block-backend.c:1473
> oracle#15 0x000061528538da6c in blockstatus_to_extents (...) at ../nbd/server.c:2374
> oracle#16 0x000061528538deb1 in nbd_co_send_block_status (...) at ../nbd/server.c:2481
> oracle#17 0x000061528538f424 in nbd_handle_request (...) at ../nbd/server.c:2978
> oracle#18 0x000061528538f906 in nbd_trip (...) at ../nbd/server.c:3121
> oracle#19 0x00006152855a7caf in coroutine_trampoline (...) at ../util/coroutine-ucontext.c:175

Cc: [email protected]
Suggested-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Signed-off-by: Fiona Ebner <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
jlevon pushed a commit to jlevon/qemu that referenced this issue Jan 7, 2025
@pbo-linaro
vvfat: fix ubsan issue in create_long_filename
0cb3ff7 
Found with test sbsaref introduced in [1].

[1] https://patchew.org/QEMU/[email protected]/

../block/vvfat.c:433:24: runtime error: index 14 out of bounds for type 'uint8_t [11]'
    #0 0x56151a66b93a in create_long_filename ../block/vvfat.c:433
    oracle#1 0x56151a66f3d7 in create_short_and_long_name ../block/vvfat.c:725
    oracle#2 0x56151a670403 in read_directory ../block/vvfat.c:804
    oracle#3 0x56151a674432 in init_directories ../block/vvfat.c:964
    oracle#4 0x56151a67867b in vvfat_open ../block/vvfat.c:1258
    oracle#5 0x56151a3b8e19 in bdrv_open_driver ../block.c:1660
    oracle#6 0x56151a3bb666 in bdrv_open_common ../block.c:1985
    oracle#7 0x56151a3cadb9 in bdrv_open_inherit ../block.c:4153
    oracle#8 0x56151a3c8850 in bdrv_open_child_bs ../block.c:3731
    oracle#9 0x56151a3ca832 in bdrv_open_inherit ../block.c:4098
    oracle#10 0x56151a3cbe40 in bdrv_open ../block.c:4248
    oracle#11 0x56151a46344f in blk_new_open ../block/block-backend.c:457
    oracle#12 0x56151a388bd9 in blockdev_init ../blockdev.c:612
    oracle#13 0x56151a38ab2d in drive_new ../blockdev.c:1006
    oracle#14 0x5615190fca41 in drive_init_func ../system/vl.c:649
    oracle#15 0x56151aa796dd in qemu_opts_foreach ../util/qemu-option.c:1135
    oracle#16 0x5615190fd2b6 in configure_blockdev ../system/vl.c:708
    oracle#17 0x56151910a307 in qemu_create_early_backends ../system/vl.c:2004
    oracle#18 0x561519113fcf in qemu_init ../system/vl.c:3685
    oracle#19 0x56151a7e438e in main ../system/main.c:47
    oracle#20 0x7f72d1a46249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #21 0x7f72d1a46304 in __libc_start_main_impl ../csu/libc-start.c:360
    #22 0x561517e98510 in _start (/home/user/.work/qemu/build/qemu-system-aarch64+0x3b9b510)

The offset used can easily go beyond entry->name size. It's probably a
bug, but I don't have the time to dive into vfat specifics for now.

This change solves the ubsan issue, and is functionally equivalent, as
anything written past the entry->name array would not be read anyway.

Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@vineel96