WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size l

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.
  - 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.

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?
Or do you have any other reason?

-- 
yamahata

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