You also need to include below code in the loop:
At the end, need to flush iotlb for all pages:
if ( iommu_flush_iotlb_psi(iommu, domain_iommu_domid(d),
(paddr_t)gfn << PAGE_SHIFT_4K, pages, ---->
"pages" means page number
!pte_present, flush_dev_iotlb) )
From: Tom Rotenberg [mailto:tom.rotenberg@xxxxxxxxx]
Sent: Monday, November 30, 2009 7:17 PM
To: Han, Weidong
Subject: Re: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines,
causes Xen to freeze for >2mins because of RMRR mappings
Can u please guid me a little bit, on how to write such function which
will work on a batch of pages?
Should i just enclose the:
pg_maddr = addr_to_dma_page_maddr(d, (paddr_t)gfn << PAGE_SHIFT_4K, 1);
if ( pg_maddr == 0 )
page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
pte = page + (gfn & LEVEL_MASK);
pte_present = dma_pte_present(*pte);
dma_set_pte_addr(*pte, (paddr_t)mfn << PAGE_SHIFT_4K);
dma_set_pte_prot(*pte, DMA_PTE_READ | DMA_PTE_WRITE);
/* Set the SNP on leaf page table if Snoop Control available */
if ( iommu_snoop )
in a loop?
On Mon, Nov 30, 2009 at 4:30 AM, Han, Weidong <weidong.han@xxxxxxxxx> wrote:
> Yes, you can add an API to map batches of pages instead of mapping each page
> in a separate call.
> RMRR regions of USB controller is ignored because they won't be used in
> guest. The RMRR 0x7dc00000 to 0x80000000 is shared by 00:02.0 and 00:02.1, it
> will be used by IGD in guest. But you can have a try to ignore it for 00:02.1.
> -----Original Message-----
> From: Tom Rotenberg [mailto:tom.rotenberg@xxxxxxxxx]
> Sent: Monday, November 30, 2009 1:56 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Han, Weidong
> Subject: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines, causes
> Xen to freeze for >2mins because of RMRR mappings
> Hi All,
> I am using a Dell E6400 machine, with IGD (Intel graphics device),
> which i'm trying to pass-through into a domU with Windows XP. When i
> assign only the 00:02.0 device, it seems to work ok, but when i try to
> assign the 00:02.1 device, the whole machine seems to freeze form more
> then 2 mins, causing a lot of messgaes in dom0, such as: SATA doesn't
> respond, etc.
> After some analysis i made, i discovered the followings:
> * When calling the (Intel) iommu_assign_device, it checks if the
> device has any details in the RMRR table, and if so it calls the
> 'iommu_prepare_rmrr_dev()' function.
> * The device 00:02.1 has an RMRR information, which details the whole
> area between: 0x7dc00000 to 0x80000000 (it contains ~9000 pages)
> * For each such page, Xen calls the 'intel_iommu_map_page()' function.
> This causes the hypercall to take a lot of time to process, and this
> makes dom0 to stop getting responds from devices, such as SATA, etc,,
> which may lead to a whole system crash.
> My question are:
> 1. Can this hypercall be in some way preemptive, so it won't stuck the
> whole system (i noticed that there are other hypercalls, which are
> preemptive) ?
> 2. Why can't the mapping of the pages, be done in batches of pages,
> instead of mapping each page in a separate call to
> 'intel_iommu_map_page()' ?
> 3. i noticed that for USB devices, the code there ignores the USB
> RMRR... can this be done also for the 00:02.1 device?
Xen-devel mailing list