WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: Intel IOMMU: Assigning IGD device: 00:02.1 on some machi

To: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
Subject: [Xen-devel] RE: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines, causes Xen to freeze for >2mins because of RMRR mappings
From: "Han, Weidong" <weidong.han@xxxxxxxxx>
Date: Mon, 30 Nov 2009 22:54:38 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 30 Nov 2009 06:56:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8686c3cd0911300317x2d85f9c7y47c7ff6e26aafb5a@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8686c3cd0911290956x3fd5af62o785378329d30776d@xxxxxxxxxxxxxx> <715D42877B251141A38726ABF5CABF2C05538D3CF2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <8686c3cd0911300317x2d85f9c7y47c7ff6e26aafb5a@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpxrruTvPCTiAgWSIeH7WwagZFUNgAG4inw
Thread-topic: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines, causes Xen to freeze for >2mins because of RMRR mappings
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