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

RE: [Xen-ia64-devel] [PATCH] Another important Xen/ia64 domU/vbd fix


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 4 Jan 2006 07:55:24 -0800
  • Delivery-date: Wed, 04 Jan 2006 16:00:48 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcYRPAJZIZgfBETgQqSYCAJ57rDDmwABIfgAAAFU9qA=
  • Thread-topic: [Xen-ia64-devel] [PATCH] Another important Xen/ia64 domU/vbd fix

> >If Xen requires virtual_mem_map, then dom0 will require it too.
> >Since dom0 can't work yet with virtual_mem_map, enabling it 
> in Xen is moot,
> >isn't it ?
> >
> >Tristan.

Yes, I agree.  For virtual_mem_map to work, I think domain0
needs to be given a granule of physical memory for each "island"
in the EFI memmap.

> Seems like that. If we add phys2mach (p!=m) concept into 
> dom0, that's not the issue then. ;-)

True.  But if domain0 owns all of physical memory, its not
an issue either.  The problem is that the current design
and implementation of Xen/ia64 management of physical memory
is half-way between two good solutions.  We will need to
choose one solution soon.  This should be a good discussion
at the Xen summit.

Dan

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


 


Rackspace

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