I upgraded the VM Guest's Debian to Linux kernel 6.0.12-1~bpo11+1 (coming from 5.10.158-2), and since then I have not had problems (too early to celeberate but this is aprox ~20hrs, where before this, there would be a kernel panic roughly every 5 minutes), instructions used inside the VM were: # Update Debian apt sources list to include backports (and contrib, non-free) sudo apt install lsb-release releaseName=$(lsb_release -cs) echo "deb http://deb.debian.org/debian/ ${releaseName} main contrib non-free deb http://deb.debian.org/debian/ ${releaseName}-updates main contrib non-free deb http://deb.debian.org/debian ${releaseName}-backports main contrib non-free deb http://security.debian.org/debian-security ${releaseName}-security main contrib non-free" | sudo tee /etc/apt/sources.list sudo apt update ## Install kernel from backports sudo apt install linux-image-6.0.0-0.deb11.6-arm64 reboot Worth noting is that my collegue reported similar issues again on a yet even newer kernel, 6.1.7-1.

I have the same symptoms on my m2 with 13.2 (22D49). Oddly enough, I also had an m1 with 13.1 and it worked fine there. I tried many different configurations of running Ubuntu as a VM (a lot of space/RAM/CPU, LVM, BTRFS, EXT4, and none of those in different combinations). It always ends in kernel panics on my M2. This is before I'm doing anything company specific. I'm just installing the OS (Ubuntu 22.10 ARM), installing Rosetta for Linux, and getting the latest updates from apt. The same steps that work on my M1 to get a reliable VM up and running, do not work on my M2 to achieve the same. A bit out of things to try, I attempted at installing Debian Bullseye just now, just to see if that would make any difference. The answer is no: [ 558.955855] ---[ end trace a3e4cf1d0e54fe7c ]--- [ 559.692513] Unable to handle kernel paging request at virtual address ffff0000fd3c3000 [ 559.692535] Mem abort info: [ 559.692542] ESR = 0x96000047 [ 559.692550] EC = 0x25: DABT (current EL), IL = 32 bits [ 559.692560] SET = 0, FnV = 0 [ 559.692567] EA = 0, S1PTW = 0 [ 559.692574] Data abort info: [ 559.692581] ISV = 0, ISS = 0x00000047 [ 559.692589] CM = 0, WnR = 1 [ 559.692597] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000046a325000 [ 559.692608] [ffff0000fd3c3000] pgd=000000046fff8003, p4d=000000046fff8003, ***=000000046fa92003, pmd=000000046f8a8003, pte=0000000000000008 [ 559.692628] Internal error: Oops: 96000047 [#2] SMP [ 559.692638] Modules linked in: joydev hid_generic usbhid hid apple_mfi_fastcharge binfmt_misc aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul libaes nls_ascii sha3_ce nls_cp437 sha3_generic sha512_ce vfat fat sha512_arm64 virtio_gpu sha2_ce virtio_dma_buf drm_kms_helper virtio_console virtio_balloon sha256_arm64 evdev sha1_ce efi_pstore virtiofs drm fuse configfs efivarfs virtio_rng rng_core ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic virtio_net net_failover failover virtio_blk xhci_pci xhci_hcd usbcore usb_common crct10dif_ce crct10dif_common virtio_pci virtio_ring virtio [ 559.692719] CPU: 4 PID: 12267 Comm: dpkg Tainted: G D W 5.10.0-21-arm64 #1 Debian 5.10.162-1 [ 559.692732] Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 1916.80.2.0.0 12/19/2022 [ 559.692748] pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) [ 559.692764] pc : clear_page+0x14/0x48 [ 559.692774] lr : kernel_init_free_pages+0x6c/0x9c [ 559.693346] sp : ffff800012743710 [ 559.693791] x29: ffff800012743710 x28: ffff00042df07800 [ 559.694232] x27: ffff00042df07800 x26: ffff00042df07800 [ 559.694674] x25: 0000000000000000 x24: ffff80001188ad00 [ 559.695114] x23: 0000000000000001 x22: ffff000000000000 [ 559.695576] x21: 0000000003f4f100 x20: ffff0000c6ad6ac0 [ 559.695999] x19: 0000000003f4f0c0 x18: 0000000000000000 [ 559.696416] x17: 0000000000000000 x16: 0000000000000000 [ 559.696833] x15: 0000aaaafb5d5430 x14: 0893670003000000 [ 559.697283] x13: 0000000418000000 x12: 0000000000000040 [ 559.697694] x11: ffff00042b54a6c8 x10: ffff800012743d40 [ 559.698094] x9 : ffff80001039acb4 x8 : ffff800008dd9df0 [ 559.698520] x7 : ffff0000c6ad6ac0 x6 : 0000000000000004 [ 559.698922] x5 : 000000000000fffd x4 : 0000000000000001 [ 559.699297] x3 : 0000000000000981 x2 : 0000000000000004 [ 559.699653] x1 : 0000000000000040 x0 : ffff0000fd3c3000 [ 559.699994] Call trace: [ 559.700325] clear_page+0x14/0x48 [ 559.700643] prep_new_page+0x64/0xe0 [ 559.700947] get_page_from_freelist+0x163c/0x1a60 [ 559.701252] __alloc_pages_nodemask+0x174/0xeac [ 559.701552] alloc_pages_current+0x90/0x150 [ 559.701851] pagecache_get_page+0x21c/0x380 [ 559.702149] grab_cache_page_write_begin+0x30/0x50 [ 559.702455] ext4_da_write_begin+0x130/0x430 [ext4] [ 559.702767] generic_perform_write+0xb4/0x1d0 [ 559.703082] ext4_buffered_write_iter+0xa4/0x184 [ext4] [ 559.703400] ext4_file_write_iter+0x64/0x6c0 [ext4] [ 559.703718] new_sync_write+0xf0/0x18c [ 559.704038] vfs_write+0x228/0x2bc [ 559.704358] ksys_write+0x70/0x100 [ 559.704680] __arm64_sys_write+0x24/0x30 [ 559.705008] el0_svc_common.constprop.0+0x80/0x1d0 [ 559.705337] do_el0_svc+0x2c/0x94 [ 559.705674] el0_svc+0x20/0x30 [ 559.705998] el0_sync_handler+0xb0/0xb4 [ 559.706377] el0_sync+0x180/0x1c0 [ 559.706735] Code: 37200121 12000c21 d2800082 9ac12041 (d50b7420) [ 559.707124] ---[ end trace a3e4cf1d0e54fe7d ]--- This is on: $ uname -a Linux vbox.transloadit.com 5.10.0-21-arm64 #1 SMP Debian 5.10.162-1 (2023-01-21) aarch64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Did Apple test this functionality before shipping? It seems like a very basic use case when it comes to running VMs (Installing a Linux ARM VM on top of Apple Virtualization on Apple Sillicon, doing nothing particular yet outside of enabling Rosetta and installing updates), yet me and all of my collueges on M2 are having these issues, while for my collegue on an M1, it is running fine, just like on my previous M1, with identical setup steps.