Hi all, When porting Xen on OMAP5, we need to add .quirks handler which returns the PLATFORM_QUIRK_DOM0_MAPPING_11. I have read the related set_memory_reg() in domain_build.c. And My question is in which case we don''t need to return PLATFORM_QUIRK_DOM0_MAPPING_11 in .quirks and how Xen handles that case to populate right P2M to dom0? Thanks. Chen Baozi
On Tue, 2013-09-03 at 20:41 +0800, Chen Baozi wrote:> When porting Xen on OMAP5, we need to add .quirks handler which > returns the PLATFORM_QUIRK_DOM0_MAPPING_11. I have read the related > set_memory_reg() in domain_build.c. And My question is in which case > we don''t need to return PLATFORM_QUIRK_DOM0_MAPPING_11 in .quirks and > how Xen handles that case to populate right P2M to dom0?DOM0_MAPPING_11 is a workaround for lack of an iommu, either in hardware (e.g. ARM SMMU) or in software (e.g. Stefano''s swiotlb patches). In the short term it seems like Stefano''s patches are going to be ready before we have an SMMU driver in the hypervisor. In any case DOM0_MAPPING_11 will hopefully go away before too long. Ian.
On Sep 3, 2013, at 8:49 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Tue, 2013-09-03 at 20:41 +0800, Chen Baozi wrote: >> When porting Xen on OMAP5, we need to add .quirks handler which >> returns the PLATFORM_QUIRK_DOM0_MAPPING_11. I have read the related >> set_memory_reg() in domain_build.c. And My question is in which case >> we don''t need to return PLATFORM_QUIRK_DOM0_MAPPING_11 in .quirks and >> how Xen handles that case to populate right P2M to dom0? > > DOM0_MAPPING_11 is a workaround for lack of an iommu, either in hardware > (e.g. ARM SMMU) or in software (e.g. Stefano''s swiotlb patches). In the > short term it seems like Stefano''s patches are going to be ready before > we have an SMMU driver in the hypervisor. > > In any case DOM0_MAPPING_11 will hopefully go away before too long.Thanks a lot. And one more question :P The reason that we cannot boot successfully without DOM0_MAPPING_11 on OMAP5 is because in that case the physical address dom0 writes to DMA controller is intermediate physical address rather than physical address. If we did the 1:1 mapping, the IPA of dom0 is then equal to the PA, in which case the DMA can work properly in dom0. Is this the right explanation why we need PLATFORM_QUIRK_DOM0_MAPPING_11 without either SMMU or swiotlb? Cheers, Baozi
On Wed, 2013-09-04 at 20:30 +0800, Chen Baozi wrote:> On Sep 3, 2013, at 8:49 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > On Tue, 2013-09-03 at 20:41 +0800, Chen Baozi wrote: > >> When porting Xen on OMAP5, we need to add .quirks handler which > >> returns the PLATFORM_QUIRK_DOM0_MAPPING_11. I have read the related > >> set_memory_reg() in domain_build.c. And My question is in which case > >> we don''t need to return PLATFORM_QUIRK_DOM0_MAPPING_11 in .quirks and > >> how Xen handles that case to populate right P2M to dom0? > > > > DOM0_MAPPING_11 is a workaround for lack of an iommu, either in hardware > > (e.g. ARM SMMU) or in software (e.g. Stefano''s swiotlb patches). In the > > short term it seems like Stefano''s patches are going to be ready before > > we have an SMMU driver in the hypervisor. > > > > In any case DOM0_MAPPING_11 will hopefully go away before too long. > > Thanks a lot. And one more question :P > > The reason that we cannot boot successfully without DOM0_MAPPING_11 on > OMAP5 is because in that case the physical address dom0 writes to DMA > controller is intermediate physical address rather than physical address. > If we did the 1:1 mapping, the IPA of dom0 is then equal to the PA, in > which case the DMA can work properly in dom0. Is this the right explanation > why we need PLATFORM_QUIRK_DOM0_MAPPING_11 without either SMMU or swiotlb?Correct. BTW, ballooning dom0 tends to destroy the 1:1 map, so it''s by no means a perfect bandaid. Ian.