> What is clear though is that you also depend on the memory 
> distribution
> across the (physical) address space: Contiguous (apart from the below-
> 4G hole) memory will likely represent little problems, but 
> sparse memory
> crossing the 44-bit boundary can't work in any case (since MFNs are
> represented as 32-bit quantities in 32-bit Dom0).
Urk. Yes, I had forgotten about the sparse problem.
> I can't say there are known problems, but I'm convinced not everything
> can work properly above the boundary of 168G. Nevertheless it is quite
> possible that most or all of the normal (not error handling) 
> code paths
> work well. Page table walks e.g. during exceptions or kexec would be
> problem candidates. And while my knowledge of the tools is rather
> limited, libxc also has - iirc - several hard coded 
> assumptions that might not hold.
What is special about 168GB? Or is that a typo? (And if it
is supposed to be 128GB, what is special about 128GB?)
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel