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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jan 23, 2024 at 08:27:18PM -0500, Patrick Plenefisch wrote:
> On Sat, Jan 20, 2024 at 8:33 PM Patrick Plenefisch <simonpatp@xxxxxxxxx>
> wrote:
> 
> >
> >
> > On Fri, Jan 19, 2024 at 6:06 AM Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > wrote:
> >
> >> On Fri, Jan 19, 2024 at 02:44:35AM -0500, Patrick Plenefisch wrote:
> >> > 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.
> >>
> >> Wow, you have certainly gone out of the beaten path here.
> >>
> >
> > Yeah, I wasn't expecting this many issues for being an early adopter of
> > Threaderipper 7000!
> >
> >
> >>
> >> > 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.
> >>
> >> OK, that's good, so that would be UEFI -> grub -> Xen -> Linux PVH?
> >>
> >
> > Correct. Inserting grub into the chain "fixes" the acpi tables and things
> > work correctly.
> >
> 
> Ok, I am not sure what I did the other day to get it to work, but I can't
> replicate *any* PVH success today. One driver (radeon or amdgpu) always
> complains the VFCT table is wrong, and leads to the symptoms previously
> reported.

Are you sure you are using Xen 4.18?  Some of the Xen logs you
provided did use Xen 4.17, which doesn't have the VFCT fix.

Can you please provide the `xl dmesg` for the non-working case when
using grub2?

Thanks, Roger.