Re: Various problems trying to vga-passthrough a Renoir iGPU to a xen/qubes-os hvm

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

 



On Wed, Dec 8, 2021 at 5:50 PM Yann Dirson <ydirson@xxxxxxx> wrote:
>
> Hi Alex,
>
> >
> > On Mon, Dec 6, 2021 at 4:36 PM Yann Dirson <ydirson@xxxxxxx> wrote:
> > >
> > > Hi Alex,
> > >
> > > > We have not validated virtualization of our integrated GPUs.  I
> > > > don't
> > > > know that it will work at all.  We had done a bit of testing but
> > > > ran
> > > > into the same issues with the PSP, but never had a chance to
> > > > debug
> > > > further because this feature is not productized.
> > > ...
> > > > You need a functional PSP to get the GPU driver up and running.
> > >
> > > Ah, thanks for the hint :)
> > >
> > > I guess that if I want to have any chance to get the PSP working
> > > I'm
> > > going to need more details on it.  A quick search some time ago
> > > mostly
> > > brought reverse-engineering work, rather than official AMD doc.
> > >  Are
> > > there some AMD resources I missed ?
> >
> > The driver code is pretty much it.  On APUs, the PSP is shared with
> > the CPU and the rest of the platform.  The GPU driver just interacts
> > with it for a few specific tasks:
> > 1. Loading Trusted Applications (e.g., trusted firmware applications
> > that run on the PSP for specific functionality, e.g., HDCP and
> > content
> > protection, etc.)
> > 2. Validating and loading firmware for other engines on the SoC.
> >  This
> > is required to use those engines.
>
> After some digging, if I understand correctly, the PSP is the 3rd IP
> getting its hw_init() called.  First comes soc15_common, then vega10_ih.
>
> - soc15_common_init_hw does some writes through nbio_v7.0 functions,
>   but does not query the hw to check before or after
> - vega10_init_hw does some register reads as part of its work, but once
>   it has written it does not check either
>
> So PSP is the first one to check that "soc15" (I'm still not sure what
> this one represents, really) is in fact alive and well.
>
> Can't we check earlier that the chip is really listening to us ?

Each SoC is made up of hardware blocks that provide various different
functionality.  They are mostly independent and mostly initialized
independently.  I'm not sure what you would want to check.  In your
case, I don't think it's an issue of the chip not being functional
overall, but rather a problem specific to the failing block somehow
related to being in a virtualized environment.

Alex


>
> >
> > I'm not too familiar with the PSP's path to memory from the GPU
> > perspective.  IIRC, most memory used by the PSP goes through carve
> > out
> > "vram" on APUs so it should work, but I would double check if there
> > are any system memory allocations that used to interact with the PSP
> > and see if changing them to vram helps.  It does work with the IOMMU
> > enabled on bare metal, so it should work in passthrough as well in
> > theory.
> >
> > Alex
> >
> >
> > >
> > > Best regards,
> > > --
> > > Yann
> >



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux