Xen project Mailing List

On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:

>From that environment (PVH dom0) can you see if you can dump the
contents of the VFCT table? I don't have a system with that table, so
not sure if this will work (because iasl is unlikely to know how to
decode it):

# acpidump -n VFCT -o table.dump
# acpixtract -a table.dump
# iasl -d vfct.dat
# cat vfct.dsl

Would be good if you can compare the output from what you get on a PV
dom0 or when running native Linux.

I'm also adding some AMD folks, as IIRC they did some fixes to Linux
in order to get some AMD graphics cards running on a PVH dom0, maybe
they can provide some additional input.

Well, this is pretty weird. I'll go into more details because it may be relevant. I had been working with ASRock support ever since I got my brand new motherboard because I couldn't see the BIOS/UEFI screens. I could boot up, and once native linux took control amdgpu got the screens/gpu working fine. I finally managed to be able to see the UEFI/BIOS setup screens by patching my VBIOS: I extracted the VBIOS image of a cheap R5 430 OEM, ran GOPupd to update the VBIOS UEFI component (GOP) from version 1.60 to 1.67. That allowed the UEFI to actually initialize and use a screen. However, I later realized that only 1 monitor was lighting up in the bios: my monitor plugged into the Radeon RX 480 that was still on VBIOS GOP 1.60. It appears the GOP was initializing the RX 480 too, despite not being flashed with the latest itself. I am working on an email to asrock support about that. Once I get into linux (native or PV), both monitors light up as expected. Also, If I boot linux PVH from grub, they also work. Those usage scenarios have acpidump output as identical. Booting linux PVH directly from UEFI (no grub), the monitors go to sleep on the RX 480, and amdgpu errors out about VFCT, but the R5 430 OEM does still have output. Interestingly, there is a different screen mode booting UEFI+PVH, the characters are basically squares, with more vertical lines than "default", maybe close to native screen resolution, but horizontally it's still "default". Booting from grub gives everything in the "default" resolution.

So what is in the VFCT Table? VFCT contains the non-GOP VIOS image of my Radeon RX 480 GPU. You can compare it to the VBIOS hosted at https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720 (Compare the end at E667 in the VFCT table to E5ff in that vbios link). I find this extra suspicious due to the above.

Now for the extra horrible things:

UEFI-booted PVH Linux doesn't support keyboard getty input, and at least some of the USB devices are not in lsusb. It also decided to vanish one of my HDD's. The `reboot` command hangs. The Power button doesn't do anything. There are several stack traces in dmesg. But Alt-SysRq-B does reboot! Luckily I could ssh in and capture the ACPI tables. They are much smaller, and VFCT is empty. Booting back to one of the working scenarios (direct linux, Grub PV, Grub PVH, UEFI PV), all of this is normal.

I've attached:

xenboot.log which is the serial log of xen+linux booting in UEFI PVH (kernel is debian's config, but patched to start at 2MiB)
dmesg.txt which is the linux dmesg that contains some nice stack traces (kernel is debian's config, but patched to start at 2MiB)
efipvh-tables.dump is ALL acpi tables from UEFI+PVH mode (acpidump -o efipvh-tables.dump)
working-tables.dump is ALL acpi tables from the other modes (acpidump -o working-tables.dump)
efipvh-vfct.dump is attached in spirit, as it is 0 bytes long (acpidump -n VFCT -o efipvh-vfct.dump)

I ran iasl, but it just said **** Unknown ACPI table signature [VFCT] and spat out the raw data table, nothing interesting

Something I can try, but have been nervous to try due to GOPupd warnings is to also flash the 1.67 GOP to the VBIOS on the RX 480. The R5 430 OEM had no such warnings.

Patrick

Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory allocation issue on Threadripper platforms)