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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Committed.  Sorry for the delay. 

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] 
> Sent: Wednesday, January 04, 2006 5:54 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); Tristan Gingold; 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] Another important 
> Xen/ia64 domU/vbd fix
> 
> >From: Magenheimer, Dan (HP Labs Fort Collins) 
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2006å1æ4æ 23:55
> >
> >> >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
> 
> Yes, we will discuss at summit. In the meantime, please give 
> this patch a check-in since it's critical to make IA64/DOMU 
> working for boxes with larger memory configuration.
> 
> Thanks,
> Kevin
> 

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