General Discussion

[qzed]

Issue for general discussions.

[jhaxhiaj]

I spent some effort to enable KVM for Linux on Surface Pro X but didn't succeed so far.
Maybe this deserves its own issue.

By default Linux boots in Exception Level 1 (Supervisor Level).
In order to enable KVM, Linux must execute in Exception Level 2 (Hypervisor Level).
My guess is that the UEFI Firmware is configured to boot every image (Windows Bootloader, USB Media, etc) in exception level 1.
However Windows for ARM includes a functional Hyper-V (which requires execution in EL2).
There must be a channel to unlock instruction execution in EL2.

The boot procedure on Surface Pro X looks similar to x86_64.
UEFI FIRWMARE -> bootmgrfw.efi -> winload.efi​ -> hvloader.dll ...
_xeroxz describes it here https://git.back.engineering/_xeroxz/Voyager

There is a lot of assumption below:
The first method to execute arbitrary code in EL2 would to via a synchronous exception call to EL2 (HVC). Instruction address can be passed via general purpose register. This require a specific exception handler at EL2 which branches to the instruction address.

The second method is similar to the first but via the secure monitor in EL3 (hvc)

I see a lot of hvc and smc calls from hvloader.dll in Ghidra however Windows does not provide public symbols for hvloader.dll, which complicate its reverse engineering .
UEFI firmware

Edit: A good starting point would be to dump the content of the exception tables in EL3 and EL2.
However this can not be done from EL1 because VBAR_EL2,3 can't be accessed from EL1.
I will see if this can be extracted from a UEFI firmware update and analyze them offline

[qzed]

Feel free to open a new issue for that! Unfortunately, this is something I know practically nothing about. But having KVM support would be awesome.

[liuyishengalan]

Thanks for your contribution to making Linux usable on SPX.
I have no experience in making Adreno GPU work in Linux, can you provide more detailed steps to guide us.
Currently, I installed the xf86-video-freedreno package in Arch Linux ARM and face a problem:
Xorg.0.log:
NO msm DRM/KMS, fallingback to fbdev/kgsl
GUI can show up without freedreno -> no GPU acceleration.
The kernel was compiled using spx/next-20220607 branch/ and boot up with DT.

[qzed]

Can you post a full dmesg log? Also what's the putput of ls -l /sys/class/drm?

In terms of user-space software, I only explicitly installed mesa (next to gnome on Arch, which may have pulled in some other dependencies). I haven't tried with xorg yet (only Wayland), but that shouldn't really make a difference.

[liuyishengalan]

There are no files under /sys/class/drm directory. My SPX cannot connect to the internet via a USB ethernet port, that's a bit hard to post the log. I will try to use mesa driver to see if anything will work.

[qzed]

In that case, I don't think mesa will work either. Does /sys/bus/platform/devices/2c00000.gpu exist?

[liuyishengalan]

2c00000.gpu does exist.

[qzed]

Do you have an SQ1 or SQ2? Also at this point I think we need a dmesg log.

[liuyishengalan]

SQ1 dmesg info

[qzed]

Okay, so might be a difference between SQ1 and SQ2. What about cat /sys/kernel/debug/devices_deferred?

[liuyishengalan]

/sys/kernel/debug/devices_deferred is a blank file

[qzed]

That means that no devices (that have drivers) wait on other drivers to load. I can't seem to find any reference to pretty much anything GPU related in your dmesg log. Can you post your kernel config?

[liuyishengalan]

The config I used is spx-5.19.rc1-arch.config