On Tue, Jan 23, 2024 at 08:27:18PM -0500, Patrick Plenefisch wrote: > On Sat, Jan 20, 2024 at 8:33 PM Patrick Plenefisch <simonp...@gmail.com> > wrote: > > > > > > > On Fri, Jan 19, 2024 at 6:06 AM Roger Pau Monné <roger....@citrix.com> > > 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....@citrix.com> > >> > 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.
