Isaku Yamahata wrote: > On x86 case p2m_lock/unlock() avoids the race, but ia64 doesn't have > such lock. > At this moment, the only HVM domain would be supported. OK, I understand we can't support pv iommu before resolving the lockless p2m issue.
> The issue is dom0 case. I suppose it can be supported by mapping > all the pages except xen pages at boot time and not iommu > mapping/unmapping because those pages are already mapped to dom0 > by intel_iommu_domain_init(). I think actually we do this. For the special pv guest Dom0, I think there is no issue here because dom0->need_iommu is actually always 0 (when Dom0 boots up and xen assigns all the devices to Dom0, xen doesn't invoke assign_device(), and invoking iommu_domain_init()/intel_iommu_domain_init() doesn't cause need_iommu(dom0) to be 1). >>> intel_iommu_domain_init() and dom0 memory size >>> calc_dom0_size() in xen/arch/ia64/domain.c calculates default dom0 >>> memory size. You should take memory for iommu page table >>> into account because the memory size for iommu page table >>> wouldn't be neglectable. probably iommu_pages = (max phys addr) >>> / PTRS_PER_PTE_4K + (some spare) where PTRS_PER_PTE_4K = (1 << >>> (PAGE_SHIFT_4K - 3)) >> Now, in intel_iommu_domain_init(), with respect to iommu mapping, >> Xen maps all the pages for Dom0 except for the pages used by Xen >> itself. >> Do you mean xen should only maps the page owned actually by Dom0? >> -- for instance, you're saying xen should not map the iommu page >> tables? -- since in Dom0 normally drivers don't touch iommu >> pagetables at all, looks the current code is OK? > > No. I meant that calc_dom0_size() should be updated. > It calculates the maximum memory size which can be passed to dom0 > safely. Without dom0_mem_size Xen VMM tries to give dom0 the maximum > memory size which is a common use case. > > On the other hand, it isn't uncommon that ia64 machine has several > hundred Giga bytes, so memory size for VT-d table would reach tens or > hundreds megabytes which can't be neglectable compared to xen heap > size. Memory for the VT-d table size should be taken into acount > in calc_dom0_size(). I'll look into this. > >>> intel_iommu_domain_init() and sparse memory. >>> To be honest, I'm not sure how it matters in practice. >>> On ia64 memory might be located sparsely. So iommu page table >>> should also sparse instead of [0, max_page] - (xen page). >>> You want to use efi_memmap_walk() instead of for loop. >> Thanks for pointing this out! >> So my understanding is: in the current intel_iommu_domain_init(), >> since xen judges by the 'max_page', actually some pages at the high >> address(possible in the middle or at the end) are not mapped while >> they should have been mapped? > > On ia64 machine there might be a big hole so that mapping all the > range [0, max_page] would cause lack of memory. Off course, it > depends on what kind of ia64 box you use. > Probably we can skip this issue and address it later if the issue > arose. I'll look into this. Thanks! -- Dexuan _______________________________________________ Xen-ia64-devel mailing list Xenfirstname.lastname@example.org http://lists.xensource.com/xen-ia64-devel