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

RE: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, 'George Dunlap' <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory
From: "Han, Weidong" <weidong.han@xxxxxxxxx>
Date: Fri, 26 Dec 2008 08:42:49 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 25 Dec 2008 16:43:23 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD603BB4A08@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <de76405a0812230455m51a8bd62ncf1b38dbccb3d442@xxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB49E5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <de76405a0812240642i42f9c1f2ud7ca7d9d1bf4e400@xxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB49F5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <715D42877B251141A38726ABF5CABF2C018E8307F7@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4A08@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acll1fNuL5oz45vYRHupJAZkz0wTxwAX2nywAAd3y2AADK4o4AAbEBSA
Thread-topic: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory
Tian, Kevin wrote:
>> From: Han, Weidong
>> Sent: Thursday, December 25, 2008 1:43 PM
>>>> 
>>>> At any rate, until we have that worked out, we should probably add
>>>> some "seatbelt" code to make sure that people don't use PoD for a
>>>> VT-d enabled domain.  I know absolutely nothing about the VT-d
>>>> code; could you either write a patch to do this check, or give me
>>>> an idea of the simplest thing to check?
>>> 
>>> Weidong works on VT-d and could give comments on exact point to
>>> check. 
>>> 
>> 
>> You can simply check "iommu_enabled" to know whether IOMMU
>> including VT-d and AMD IOMMU is used or not.
>> 
> 
> Weidong, does iommu_enabled indicate IOMMU h/w availability?
> Then you'll have this nice feature disabled on most new platform
> with IOMMU shipped. :-) Here a domain-based check is required,
> i.e. PoD is only appliable when target domain is not passthroughed
> with any device.
> 
> Thanks,
> Kevin

iommu_enabled will be set when IOMMU h/w is available and user sets "iommu=1" 
in grub to use it. Because device hotplug with VT-d is already supported, I 
think domain-based check is not enough, it's better to disable PoD when 
iommu_enabled is set. 

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