[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Han, Weidong" <weidong.han@xxxxxxxxx>
  • Date: Mon, 30 Nov 2009 10:30:17 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Sun, 29 Nov 2009 18:32:25 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpxHUQcaOAnAQCFScSSWgpncXaPgQAQ+b5Q
  • Thread-topic: Intel IOMMU: Assigning IGD device: 00:02.1 on some machines, causes Xen to freeze for >2mins because of RMRR mappings

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.