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

["Deucher, Alexander" <Alexander.Deucher@xxxxxxx>]

[Public]

> -----Original Message-----
> From: Huang, Ray <Ray.Huang@xxxxxxx>
> Sent: Friday, January 19, 2024 4:55 AM
> To: Patrick Plenefisch <simonpatp@xxxxxxxxx>
> Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>; Jan Beulich
> <jbeulich@xxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Juergen Gross
> <jgross@xxxxxxxx>; Chen, Jiqian <Jiqian.Chen@xxxxxxx>; Deucher,
> Alexander <Alexander.Deucher@xxxxxxx>
> Subject: Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory
> allocation issue on Threadripper platforms)
>
> On Fri, Jan 19, 2024 at 03:44:35PM +0800, Patrick Plenefisch wrote:
> >    On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné
> >    <[1]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
>
> Thanks Roger to involve us. The VFCT table is to expose video BIOS image by
> AMD GPUs. You can see details here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> /gpu/drm/amd/include/atombios.h
>
> Did you apply this patch?
>
> https://lore.kernel.org/xen-devel/20230312075455.450187-2-
> ray.huang@xxxxxxx/
>

VFCT is generated on the fly by the system bios at boot.  The system bios 
fetches the PCI rom image from the AMD display devices and uses them to 
populate the VFCT table.

Alex


> Thanks,
> Ray
>
> >    my Radeon RX 480 GPU. You can compare it to the VBIOS hosted at
> >    [2]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
> >
> > References
> >
> >    1. mailto:roger.pau@xxxxxxxxxx
> >    2. https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-
> 160720