[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Patrick Plenefisch <simonpatp@xxxxxxxxx>
  • From: Huang Rui <ray.huang@xxxxxxx>
  • Date: Fri, 19 Jan 2024 17:54:31 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FfYZBIRYDsek3oo3J1UeIqyTfQfsbwCYKillH0oExJI=; b=TKbKrxxeDVconIrmHIjfdZrpgSorHpd8a7SNlnj++NN5Wk3dhQFI3jL51y9GylRAC2N58Flu/sJejoAjRLfaEt/X9MG26/bjI+o5wGNNwN3ColNlQ929n3u3f54cyebSxd+3AoTmxaV+m4eHL02+LKP/QSyFEldYyUzQ2zWhUWXdRSb5KPKzMWXFlURLwDZTiglVVpHk25/Y0CnLkD0Qgf1QxpTMwvue8klqfNXs/WRDvKv/3NcKaGLtN4UwppTY8g9sJiAh0VTNzpc+L5q4m6iPI6p/v6hlOMgYxpyvtgV8ffLLYRFXi8tYV/0NvHResB4RvhcoRgWC75iETGRseg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LgnLm8NRMHLvBaqL0r7h/mkft+I5iyY65v/jZZHqWymHaitCUsDFXbEK0K7KAVx487W/PemeQnVg+JbgP7jNjGUPF6P2+kxhhkxKRJFOXHJ7CyHU7QHBZNWDnUv4gpAKM22ebI3OxKScCJ4DEh8zygz0NcAcux/KIVO6QePtcgG1aFFuhTygvEIWSlMYZ9jgjHNKBooAbN7eUWCfp9z0tAUFMQpTb0OqQYkT2qgAjYsnZasZFKlN52ls585LLDD/XzcCj10jNpU0VWwbnt8LC85k2kkjR86Yf7nx3DEbEdWGz1zjGG2eCIT3pTbi5Sd2fBLVDsKcaqFeYV/VSYt8vQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>, Alex Deucher <alexander.deucher@xxxxxxx>
  • Delivery-date: Fri, 19 Jan 2024 09:55:00 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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/

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.