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-ia64-devel

RE: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentpara

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 2 Nov 2005 08:59:01 +0800
Cc: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 Nov 2005 00:56:02 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXerXo76q/haFr+QWGubs2JLsu1/QAAmd0wAA7Ef8AAFYikMAAAbOUwAAFx8jA=
Thread-topic: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>> However, I agree with Matt that a PMT for other domains
>>> (domU) is a bad idea as it creates many problems for migration,
>>> save/restore, ballooning, and adding new domains to an already
>>> loaded system. Further, the grant table abstraction is the primary
>>> mechanism for page sharing for domU in Xen (on Xen/x86).
>>> I think if domU has any knowledge of actual machine addresses,
>>> the Xen team would consider this a bug that should be fixed.
>>> 
>> Dan:
>>      I think you get right reverse solution, without PMT in
>> domU is a nightmare for migration, balloning and etc.. We
>> (Matt, Kevin and me) believe PMT for domU is a must, because
>> domU don't want to know where the physical page is located,
>> so gpn will always be from 0 for example while mfn may start
>> from any address, this is what PMT does to translate from gpn
>> to mfn. Today's dom0 is assume gpn=mfn so no PMT table yet,
>> that is what we are discussing to let dom0 have PMT same with domU.
>>      I guess you are probably assuming the PMT is a Xenlinux
>> stuff, actually PMT is a HV data structure even in Xen/X86
>> and Xen/IA64-VTi. HV need to use PMT to insert machine side
>> TLB for example, and sharing HV PMT to paravirtualized guest
>> should be done so that VBD and VNIF can refer to. With PMT in
>> dom0, we are just stepping toward close to Xen/X86 and reduce
>> various maintaince effort and deviation.
> 
> Well clearly we are not on the same page regarding the definition
> of PMT, so it is good for you to define what you mean.  I did
> assume that you were referring to a data structure that is
> accessible to both domain and hypervisor. This is what Matt and I are
> arguing against for domU.  If it is not visible, there is already
> a "PMT" in Xen which translates domU physical addresses to machine
> addresses.  It is just implemented as a multi-level page table
> rather than one large 1-1 mapping table.  (And this is necessary
> because we don't want to require allocation of large contiguous memory
> blocks after dom0 boots.)
> 
> So, I guess we are in agreement.  We will look at the possibility
> of adding a PMT visible to both Xen and domain0 (and in the future
> also driver domains) and domU's will not have access to any
> machine address information via a PMT or any other data structure
> (but Xen of course will need to maintain this information).
> Correct?
> 
> Thanks,
> Dan

Yes! :-)
Eddie

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