Re: Reg. Tee init fail...

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 6/29/22 4:03 PM, Stefano Stabellini wrote:
> Adding Juergen and Boris because this is a Linux/x86 issue.
>
>
> As you can see from this Linux driver:
> https://elixir.bootlin.com/linux/latest/source/drivers/crypto/ccp/tee-dev.c#L132
>
> Linux as dom0 on x86 is trying to communicate with firmware (TEE). Linux
> is calling __pa to pass a physical address to firmware. However, __pa
> returns a "fake" address not an mfn. I imagine that a quick workaround
> would be to call "virt_to_machine" instead of "__pa" in tee-dev.c.

It's probably worth a try but it seems we may need to OR the result with C-bit 
(i.e. sme_me_mask). Or (for testing purposes) run with TSME on, I think C-bit 
is not set then.


-boris


> Normally, if this was a device, the "right fix" would be to use
> swiotlb-xen:xen_swiotlb_map_page to get back a real physical address.
>
> However, xen_swiotlb_map_page is meant to be used as part of the dma_ops
> API and takes a struct device *dev as input parameter. Maybe
> xen_swiotlb_map_page can be used for tee-dev as well?
>
>
> Basically tee-dev would need to call dma_map_page before passing
> addresses to firmware, and dma_unmap_page when it is done. E.g.:
>
>
>    cmd_buffer = dma_map_page(dev, virt_to_page(cmd),
>                              cmd & ~PAGE_MASK,
>                              ring_size,
>                              DMA_TO_DEVICE);
>
>
> Juergen, Boris,
> what do you think?
>
>
>
> On Fri, 24 Jun 2022, Julien Grall wrote:
> > Hi,
> >
> > (moving the discussion to xen-devel as I think it is more appropriate)
> >
> > On 24/06/2022 10:53, SK, SivaSangeetha (Siva Sangeetha) wrote:
> > > [AMD Official Use Only - General]
> > Not clear what this means.
> >
> > > Hi Xen team,
> > >
> > > In TEE driver, We allocate a ring buffer, get its physical address from
> > > __pa() macro, pass the physical address to secure processor for mapping it
> > > and using in secure processor side.
> > >
> > > Source:
> > > https://elixir.bootlin.com/linux/latest/source/drivers/crypto/ccp/tee-dev.c#L132
> > >
> > > This works good natively in Dom0 on the target.
> > > When we boot the same Dom0 kernel, with Xen hypervisor enabled, ring init
> > > fails.
> > Do you have any error message or error code?
> >
> > > We suspect that the address passed to secure processor, is not same when xen
> > > is enabled, and when xen is enabled, some level of address translation might
> > > be required to get exact physical address.
> > If you are using Xen upstream, Dom0 will be mapped with IPA == PA. So there
> > should be no need for translation.
> >
> > Can you provide more details on your setup (version of Xen, Linux...)?
> >
> > Cheers,
> >
> > --
> > Julien Grall