[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Reg. Tee init fail...
On Thu, Jun 30, 2022 at 07:31:38AM +0200, Juergen Gross wrote: > On 30.06.22 05:32, SK, SivaSangeetha (Siva Sangeetha) wrote: > > [AMD Official Use Only - General] > > > > +team > > > > -----Original Message----- > > From: Stefano Stabellini <sstabellini@xxxxxxxxxx> > > Sent: Thursday, June 30, 2022 1:34 AM > > To: Julien Grall <julien@xxxxxxx> > > Cc: SK, SivaSangeetha (Siva Sangeetha) <SivaSangeetha.SK@xxxxxxx>; > > xen-devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini > > <sstabellini@xxxxxxxxxx>; Bertrand Marquis <bertrand.marquis@xxxxxxx>; > > Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>; jgross@xxxxxxxx; > > boris.ostrovsky@xxxxxxxxxx > > Subject: Re: Reg. Tee init fail... > > > > Adding Juergen and Boris because this is a Linux/x86 issue. > > > > > > As you can see from this Linux driver: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fcrypto%2Fccp%2Ftee-dev.c%23L132&data=05%7C01%7CSivaSangeetha.SK%40amd.com%7Ce962a907794f4917a80b08da5a0a7b3b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637921298315828104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NxmMUckiDRGLv3qLJrhZKBt2zNTuomEZqYJdV74tXxA%3D&reserved=0 > > > > 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. > > > > 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? > > Yes, I think using the DMA interface is the correct way to handle that. > > BTW, I did a similar fix for the dcdbas driver recently: > > https://lore.kernel.org/r/20220318150950.16843-1-jgross@xxxxxxxx I hit similar issue, and the patch below made it work for me (ugly workaround), or at least stop complaining. But note one of those places have this comment: /* We need actual physical address instead of DMA address, since * Trusted OS running on AMD Secure Processor will map this region */ I guess it means AMD Secure Processor bypasses IOMMU... ---8<--- diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c index 5c9d47f3be37..9d440fc8a56d 100644 --- a/drivers/crypto/ccp/tee-dev.c +++ b/drivers/crypto/ccp/tee-dev.c @@ -15,6 +15,7 @@ #include <linux/gfp.h> #include <linux/psp-sev.h> #include <linux/psp-tee.h> +#include <xen/page.h> #include "psp-dev.h" #include "tee-dev.h" @@ -39,7 +40,7 @@ static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size) memset(start_addr, 0x0, ring_size); rb_mgr->ring_start = start_addr; rb_mgr->ring_size = ring_size; - rb_mgr->ring_pa = __psp_pa(start_addr); + rb_mgr->ring_pa = virt_to_machine(start_addr).maddr; mutex_init(&rb_mgr->mutex); return 0; @@ -129,7 +130,7 @@ static int tee_init_ring(struct psp_tee_device *tee) return -ENOMEM; } - cmd_buffer = __psp_pa((void *)cmd); + cmd_buffer = virt_to_machine((void *)cmd).maddr; /* Send command buffer details to Trusted OS by writing to * CPU-PSP message registers -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab Attachment:
signature.asc
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |