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
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home