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

RE: [Xen-devel] Uses of &frame_table[xfn]


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 28 Dec 2005 14:30:39 -0800
  • Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 28 Dec 2005 22:34:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYHzbGsp/tYmOukSW+YY8FNtaIiYwALZ7OwAH5XjuAAggoFcA==
  • Thread-topic: [Xen-devel] Uses of &frame_table[xfn]

Thanks for your reply Kevin.   The explanation is helpful.

> All such troubles come from no phys2mach mapping table within 
> ia64 dom0! So Dan, maybe it's time to revise current ia64 
> xenlinux design to make life easier. ;-)

This is an important question.  In my opinion, it may make
life easier to mimic the x86 memory management scheme.  But
I believe one of the roles of Xen/ia64 as the first non-x86
port is to identify code existing in Xen and Xenlinux that
is x86-specific and help to define a better architecture-
independent interface.  I think the whole concept of a
guest-visible phys2mach table is a necessary evil on x86
because the guest writes page tables that are walked by
hardware.  This is of questionable use on other architectures
(and even on x86 in full shadow mode?).

Since you raised the question, let's pose it to the core
Xen team and other arch developers.  I'll start a new thread...

Thanks,
Dan

_______________________________________________
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®.