[Xen-devel] RE: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines, causes Xen to freeze for >2mins because of RMRR mappings

["Han, Weidong" <weidong.han@xxxxxxxxx>]

You also need to include below code in the loop:
    iommu_flush_cache_entry(pte);
    unmap_vtd_domain_page(page);

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) )
            iommu_flush_write_buffer(iommu);

Regards,
Weidong

-----Original Message-----
From: Tom Rotenberg [mailto:tom.rotenberg@xxxxxxxxx] 
Sent: Monday, November 30, 2009 7:17 PM
To: Han, Weidong
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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 )
    {
        spin_unlock(&hd->mapping_lock);
        return -ENOMEM;
    }
    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 )
        dma_set_pte_snp(*pte);
...
"

in a loop?

On Mon, Nov 30, 2009 at 4:30 AM, Han, Weidong <weidong.han@xxxxxxxxx> wrote:
> Tom,
>
> 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.
>
>
> Regards,
> Weidong
>
> -----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?
>
> Tom
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel