KVM enabled? #26

kyr0 · 2022-04-05T23:54:48Z

Do I see it correctly that KVM is enabled?

https://github.com/AsahiLinux/linux/blob/asahi/arch/arm64/configs/defconfig#L110

Or is this configuration overwritten somewhere?

Sry, I'm a bit out of kernel stuff since a few years. Need some time to get back to this business

Because if that works and qemu compiles and runs well (yeah, yeah, the 16k page size fun), we'd be able to run KVM acceleration enabled qemu on an M1?

https://community.arm.com/oss-platforms/w/docs/510/spawn-a-linux-virtual-machine-on-arm-using-qemu-kvm

The text was updated successfully, but these errors were encountered:

jannau · 2022-04-06T05:59:58Z

Please do not use github issues as discussion forum.

qemu with kvm works well out of the box on M1 Pro/Max/Ultra. On the original M1 it needs an unreleased qemu version to work well out of the box. It work afaik with higmem=off 16k page size is not a problem for qemu.

kyr0 · 2022-04-06T13:06:26Z

You're right, thank you. On top of that (I tested and verified it yesterday night), it runs SerenityOS without any problems.
However KVM support wasn't working by default but I guess that is out of scope here as it is an issue about what qemu system binary to use in regards to pure ARM KVM support.

Leaving it here for reference for whenever someone has the same "issue": https://community.arm.com/oss-platforms/w/docs/510/spawn-a-linux-virtual-machine-on-arm-using-qemu-kvm

I'll probably fix/PR the issue for SerenityOS (guest) so that it makes use of KVM functionality when running on Ashai (host); specifically if/else case needs to be added for using qemu-system-aarch64 with qemu on Ashai; https://github.com/SerenityOS/serenity/blob/master/Meta/run.sh#L38

I'll just report back tonight if that worked but it's fine if we close this issue right now. Thank you

pimpmypicture · 2022-04-24T14:34:30Z

Regarding initial question, qemu 7.0 brought compatibility with KVM on original M1.

Alas, a bug was found when enabling smp (https://gitlab.com/qemu-project/qemu/-/issues/1002).
There is a workaround but you must compile qemu yourself (and revert a specific commit).

pbo-linaro · 2022-05-03T19:47:57Z

Regarding previous message, is seems like KVM currently does not support a cpu having two different kind of cores (like M1).
Full details: https://gitlab.com/qemu-project/qemu/-/issues/1002#note_933186950

So reverting the commit on qemu does not really solve the original problem (only a part of it).

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

t8103: - WLAN (SMC PMU GPIO AsahiLinux#13) t600x: - WLAN (SMC PMU GPIO AsahiLinux#13) - SD (SMC PMU GPIO AsahiLinux#26) Signed-off-by: Hector Martin <[email protected]>

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

t8103: - WLAN (SMC PMU GPIO AsahiLinux#13) t600x: - WLAN (SMC PMU GPIO AsahiLinux#13) - SD (SMC PMU GPIO AsahiLinux#26) Signed-off-by: Hector Martin <[email protected]>

Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

t8103: - WLAN (SMC PMU GPIO AsahiLinux#13) t600x: - WLAN (SMC PMU GPIO AsahiLinux#13) - SD (SMC PMU GPIO AsahiLinux#26) Signed-off-by: Hector Martin <[email protected]>

As of commit b92143d ("net: dsa: mv88e6xxx: add infrastructure for phylink_pcs") probing of a Marvell 88e6350 switch causes a NULL pointer de-reference like this example: ... mv88e6085 d0072004.mdio-mii:11: switch 0x3710 detected: Marvell 88E6350, revision 2 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 8 Comm: kworker/u2:0 Not tainted 6.7.0-rc2-dirty #26 Hardware name: Marvell Armada 370/XP (Device Tree) Workqueue: events_unbound deferred_probe_work_func PC is at mv88e6xxx_port_setup+0x1c/0x44 LR is at dsa_port_devlink_setup+0x74/0x154 pc : [<c057ea24>] lr : [<c0819598>] psr: a0000013 sp : c184fce0 ip : c542b8f4 fp : 00000000 r10: 00000001 r9 : c542a540 r8 : c542bc00 r7 : c542b838 r6 : c5244580 r5 : 00000005 r4 : c5244580 r3 : 00000000 r2 : c542b840 r1 : 00000005 r0 : c1a02040 ... The Marvell 6350 switch has no SERDES interface and so has no corresponding pcs_ops defined for it. But during probing a call is made to mv88e6xxx_port_setup() which unconditionally expects pcs_ops to exist - though the presence of the pcs_ops->pcs_init function is optional. Modify code to check for pcs_ops first, before checking for and calling pcs_ops->pcs_init. Modify checking and use of pcs_ops->pcs_teardown which may potentially suffer the same problem. Fixes: b92143d ("net: dsa: mv88e6xxx: add infrastructure for phylink_pcs") Signed-off-by: Greg Ungerer <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

t8103: - WLAN (SMC PMU GPIO AsahiLinux#13) t600x: - WLAN (SMC PMU GPIO AsahiLinux#13) - SD (SMC PMU GPIO AsahiLinux#26) Signed-off-by: Hector Martin <[email protected]>

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv(). Suggested-by: Eric Dumazet <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Fixes: e994b2f ("tcp: do not lock listener to process SYN packets") Signed-off-by: Wang Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>

t8103: - WLAN (SMC PMU GPIO AsahiLinux#13) t600x: - WLAN (SMC PMU GPIO AsahiLinux#13) - SD (SMC PMU GPIO AsahiLinux#26) Signed-off-by: Hector Martin <[email protected]>

asahilina pushed a commit that referenced this issue Aug 17, 2022

arm64: dts: apple: Add PCI power enable GPIOs

8d2ddae

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

asahilina pushed a commit that referenced this issue Aug 17, 2022

arm64: dts: apple: Add PCI power enable GPIOs

e1a42fe

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan closed this as completed Sep 9, 2022

marcan added a commit that referenced this issue Sep 12, 2022

arm64: dts: apple: Add PCI power enable GPIOs

a744c9c

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan added a commit that referenced this issue Sep 12, 2022

arm64: dts: apple: Add PCI power enable GPIOs

16d4644

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan added a commit that referenced this issue Nov 28, 2022

arm64: dts: apple: Add PCI power enable GPIOs

63942b8

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan added a commit that referenced this issue Nov 28, 2022

arm64: dts: apple: Add PCI power enable GPIOs

2f4a334

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan added a commit that referenced this issue Apr 24, 2023

arm64: dts: apple: Add PCI power enable GPIOs

8ed1721

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

marcan added a commit that referenced this issue Apr 24, 2023

arm64: dts: apple: Add PCI power enable GPIOs

a7eb61c

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

svenpeter42 pushed a commit that referenced this issue Apr 17, 2024

arm64: dts: apple: Add PCI power enable GPIOs

d43e231

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

svenpeter42 pushed a commit that referenced this issue Apr 17, 2024

arm64: dts: apple: Add PCI power enable GPIOs

4cee22f

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

jannau pushed a commit that referenced this issue Apr 29, 2024

arm64: dts: apple: Add PCI power enable GPIOs

868dda9

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

jannau pushed a commit that referenced this issue Apr 29, 2024

arm64: dts: apple: Add PCI power enable GPIOs

095c7f4

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

jannau pushed a commit that referenced this issue Jun 4, 2024

arm64: dts: apple: Add PCI power enable GPIOs

1e66aa8

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

jannau pushed a commit that referenced this issue Jun 4, 2024

arm64: dts: apple: Add PCI power enable GPIOs

0156270

t8103: - WLAN (SMC PMU GPIO #13) t600x: - WLAN (SMC PMU GPIO #13) - SD (SMC PMU GPIO #26) Signed-off-by: Hector Martin <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

KVM enabled? #26

KVM enabled? #26

kyr0 commented Apr 5, 2022 •

edited

Loading

jannau commented Apr 6, 2022

kyr0 commented Apr 6, 2022 •

edited

Loading

pimpmypicture commented Apr 24, 2022

pbo-linaro commented May 3, 2022

KVM enabled? #26

KVM enabled? #26

Comments

kyr0 commented Apr 5, 2022 • edited Loading

jannau commented Apr 6, 2022

kyr0 commented Apr 6, 2022 • edited Loading

pimpmypicture commented Apr 24, 2022

pbo-linaro commented May 3, 2022

kyr0 commented Apr 5, 2022 •

edited

Loading

kyr0 commented Apr 6, 2022 •

edited

Loading