@VMware : any idea on how to handle ID_AA64ISAR2_EL1 ?

[fabienmagagnosc]

Not much to add

the list now of post related to this is really painful now

• Linux 5.17 EFI-stub does not boot, hangs at loading kernel.

• Failure to boot Linux Kernel 5.15.31, works with 5.15.26

• Anyone have any luck with Ubuntu 5.15 kernels?

• Fedora 35 kernel 5.16.14 will not boot

• ... probably more

@Mikero=> just an update maybe would be great thanks

[Mikero]

The patch fix was put into 5.17.2, 5.16.19 and 5.15.33.

[fabienmagagnosc]

Thanks @Mikero which means now :

Workstation :

• Fedora 37 is NOK : kernel-5.18.0-0.rc2.23.fc37
• Fedora 36 is OK when available (under testing) : kernel-5.17.2-300.fc36
• Fedora 35 is OS when available (under testing) : kernel-5.16.19-200.fc35
• Fedora 34 is OK when available (under testing) : kernel-5.16.19-100.fc34

Server :

• CentOS Stream 9 is NOK, using 5.14 : http://mirror.stream.centos.org/9-stream/BaseOS/aarch64/os/Packages/
• Ubuntu 20.04 (Focal) is available (manually): https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.16.19/
• Ubuntu 21.10 (Himpi) is available (manually): https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.2/
• Ubuntu 22.04 (Jammy) is available (manually): https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.2/

I'll do the testing for Fedora at least within this week as Ubuntu (even we don't really use it), waiting for Fedora/CentOS Stream mostly

[gnattu]

Sorry @Mikero, I downloaded 5.17.2 kernel from kernel.org, complied it, and it still hangs at loading kernel.

The fix you mention is probably this one: 

fbdev: Hot-unplug firmware fb devices on forced removal

Yes, this caused a boot bug on ubuntu but most of us using a recent kernel now is facing another problem due to a new kernel feature.

Recent kernels added support for reading ID_AA64ISAR2_EL1 register and such read, to my understanding will trap into the hypervisor which handles them as faults, and blocking the kernel to boot. Both Parallels and QEMU already landed fixes to correctly handle such register reading. QEMU fixed this by treating all unknown register IDs reads as RES0 register reads. 

I believe this is a problem that requires a patch to VMware fusion to fix.

As a workaround now, I made a patchset which removed ID_AA64ISAR2_EL1 register support from the 5.17 kernel: https://gist.github.com/gnattu/c114091013cac6a6c36394c7a572281c

[Mikero]

Ah yes, you're totally right... My bad, getting the1 bugs mixed up!

Double checking on this one, looks like it's on us. We have it addressed internally but it wasn't quite ready with the last update to the TP.

I'll see what we can do to get this fix out.

(anyone at VMW looking at this, it's bug 2634231)

[fabienmagagnosc]

Maybe you could see to have for every post a skeleton where we can put :

   - the OS (fedora …)

   - the kernel version 

   - a way to link ticket together, like having an internal ticket number, and we can see those are similar/the same see to link them together

it’s a little bit “furry’ now in the community as there are more feedback, but hard to search or at least try to aggregate the issues and expose the knowledge

thanks for the support

[Technogeezer]

@Mikero this is good news that you've at least addressed this internally. We're all holding our collective breaths for this.  

@fabienmagagnosc - I agree that the kernel fixes should not be backed out. From what I read of the situation, the check is there in preparation for a new instruction in the ARM v9 architecture that will be used in the mitigation of Spectre beyond what's available today.

Also - I maintain the tips/techniques document found here: https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/Tips-Techniques-Gotchas-for-the-Tech... I'd be happy to put something in it to help clarify the situation - I did create it to help summarize things that may be scattered across multiple threads in this forum. if you have any suggestions on what would look good, I'll take them... (PM me if you'd like...)