On Fri, 2007-08-03 at 11:12 +0900, Isaku Yamahata wrote: > On Thu, Aug 02, 2007 at 10:00:46AM -0500, Hollis Blanchard wrote: > > On Thu, 2007-08-02 at 11:44 +0900, Isaku Yamahata wrote: > > > > > > > But we can issue sequential p2m hcalls with different offsets, so we > > > do. > > > > So what exactly is the new problem? > > > > > > The limit is about 64GB for xen/ia64 because xen/ia64 deafult page > > > size > > > is 16KB. > > > The issue I'm seeing is the populate physmap hypercall failure > > > at domain creation. It's essentially same issue you described above. > > > I want to remove the limitation with the patches. > > > > Can't you simply issue repeated populate_physmap hypercalls, > > incrementing extent_start? > > Yes, it's possible. However my choice was to generalize xencomm > because > - The inline xencomm code already supports page boundary crossing. > - IMHO it doesn't unnecessarily complicate the existing code.
Well, your patch was largish... > - Anyway struct xencomm_desc page boundary crossing check should > be done because a hostile guest can pass such a pointer. > Without the check, xencomm code may access first 4bytes of > the unrelated page as desc->nr_addrs. Good point. > If you are reluctant to patch xencomm code because of testing, > how about, consolidate xencomm code at first, next test the patch > with xen/ia64, then merge the patch? This sounds good to me. Thanks. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
