|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v03 04/10] arm: introduce remoteprocessor iommu module
Hi Andrii,I'm still concerned about security with this patch. Only one guest should be able to access to a specific remoteproc at the same time. Therefore it should be the same for the MMU. AFAIU, even with XSM, you are still registering every MMU for every domain that want to access to a remoteproc. You have to find a way to say "This domain will be able to handle this remoteproc", maybe by keeping a list of MMU per domain. On 02/09/14 08:46, Andrii Tseglytskyi wrote: diff --git a/xen/arch/arm/remoteproc/Makefile b/xen/arch/arm/remoteproc/Makefile new file mode 100644 index 0000000..0b0ee0e --- /dev/null +++ b/xen/arch/arm/remoteproc/Makefile @@ -0,0 +1 @@ [..] Maybe "static const"? AFAIU, you will add callbacks in this structure in subsequent patch, right?If so, I would let the remoteproc driver adds the callback itself, even if it's done at compile time. You can give a look to the platform code. [..] allocate allocate + return NULL; + } + + /* alocate pagetable for ipa storing */ allocate IPA [..] map_domain_page can't fail. Therefore the check is not necessary. + pr_mmu(mmu, "failed to map pte table"); + return INVALID_PADDR; + } + + clean_and_invalidate_xen_dcache_va_range(pte_table, PAGE_SIZE); I would add a comment explaining why "clean_and_invalidate_..." is necessary here. Braces are not necessary. [..] + unmap_domain_page(pte_table); + + clean_and_invalidate_xen_dcache_va_range(hyp_pte_table, MMU_PTE_TABLE_SIZE(mmu)); We use to put a blank line before the last return. Shouldn't you check that the remoteproc MMU will work with the current board? As it's generic, people may want to run the same Xen on multiple platform, some of them may use remoteproc. We don't want to let the other board to use some (if not all) MMU drivers. [..] Thinking about the MMIO handler, I would extend register_mmio_handler to take a data pointer in parameter. This pointer will be your MMU. It will avoid the waste of time looking to the MMU and make the code a simpler. [..] I don't see any call of this function in xen/arch/arm/domain.c. Is it normal? To continue on my comment at the beginning of this mail, I don't think we should register every MMU callbacks to each domain which will use remoteproc. Also, what about domain destruction? Shouldn't you free the MMU page table to save space? Again, what will happen if an MMU has been initialized? I guess bad things... do_initcalls doesn't check the return of the initcall and will silently ignore any error. I'm not sure if the common (i.e ARM & x86) sense is to return 0 if sucess. So may be a panic will be the best here. +__initcall(mmu_init_all); + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/asm-arm/remoteproc_iommu.h b/xen/include/asm-arm/remoteproc_iommu.h new file mode 100644 index 0000000..6fa78ee --- /dev/null +++ b/xen/include/asm-arm/remoteproc_iommu.h @@ -0,0 +1,82 @@ +/* + * xen/include/xen/remoteproc_iommu.h xen/include/asm-arm/remoteproc_iommu.h + * + * Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx> + * Copyright (c) 2014 GlobalLogic + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _REMOTEPROC_IOMMU_H_ +#define _REMOTEPROC_IOMMU_H_ We use to add the directory in the header name. I.E __ARM_REMOTEPROC_IOMMU_H__ And of course fixing at the end of the file too :). Hard Tab. + paddr_t (*translate_pfunc)(struct mmu_info *, struct mmu_pagetable *); Same here. + int (*copy_pagetable_pfunc)(struct mmu_info *mmu, struct mmu_pagetable *pgt); + void (*print_pagetable_pfunc)(struct mmu_info *); +}; + +int remoteproc_iommu_register_mmio_handlers(struct domain *dom); + +paddr_t remoteproc_iommu_translate_second_level(struct mmu_info *mmu, + struct mmu_pagetable *pgt, + paddr_t maddr, paddr_t hyp_addr); + +#endif /* _REMOTEPROC_IOMMU_H_ */ We use to add the following lines at the end of the file: /* * Local variables: * mode: C * c-file-style: "BSD" * c-basic-offset: 4 * indent-tabs-mode: nil * End: */ Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |