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/
Home Products Support Community News


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

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Matt Chapman" <matthewc@xxxxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 1 Nov 2005 16:31:42 -0800
Cc: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 Nov 2005 00:28:39 +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/QAAmd0wAA7Ef8AAFYikMAAAbOUw
Thread-topic: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
> > 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).


Xen-ia64-devel mailing list