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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home