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-ia64-devel

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

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [XenPPC] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side)
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Thu, 2 Aug 2007 11:44:39 +0900
Cc: xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 01 Aug 2007 19:42:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1185995274.15389.21.camel@basalt>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070731061019.GB6039%yamahata@xxxxxxxxxxxxx> <1185913517.6802.74.camel@bling> <20070801063654.GD14448%yamahata@xxxxxxxxxxxxx> <1185995274.15389.21.camel@basalt>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Wed, Aug 01, 2007 at 02:07:54PM -0500, Hollis Blanchard wrote:
> On Wed, 2007-08-01 at 15:36 +0900, Isaku Yamahata wrote:
> > remove xencomm page size limit.
> > Currently xencomm has page size limit so that a domain with many memory
> > (e.g. 100GB+) can't be created.
> > This patch allows that the address array of struct xencomm_desc to cross
> > page boundary so that the size of struct xencomm_desc can exceed page size.
> > Note that struct xencomm_desc itself can't page boundary. 
> 
> I'm confused about this.
> 
> We noticed a much smaller limit doing save/restore. The p2m mapping
> maxed out at 512MB:
>       * a xencomm_desc must fit into 1 page (1<<12)
>       * it contains approx 1<<9 64-bit entries
>       * each entry points to a page of memory containing 1<<9 entries of
>         the p2m array
>       * total: 1<<18 p2m entries
>       * each p2m entry represents a guest page (1<<12)
>       * 1<<30 total guest memory can be represented with a single
>         xencomm_desc
> 
> 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.


> Secondly, your patch doesn't make much sense to me, because the Xen side
> is explicitly rejecting xencomm_descs that cross a page boundary. So
> even if Linux sends down a multipage descriptor, Xen will return EINVAL.
> Am I missing something?

The patch description should have been clearer.
It confuses struct xencomm_desc itself (note sizeof(struct xencomm_descs) = 8)
with xencomm_desc->address[] variable sized array.
Please remember
struct xencomm_desc {
    uint32_t magic;
    uint32_t nr_addrs; /* the number of entries in address[] */
    uint64_t address[0];
};

Yes, struct xencomm_descs itself (8 bytes) can not cross page boundary.
But I want to allow the xencomm_descs->address[] variable sized array
to cross page boundary so that nr_addrs can be greater than
((PAGE_SIZE - sizeof(*desc)) / sizeof(desc->address[0]))
where struct xencomm_desc *desc;


> (As a side question, is it really so difficult for you guys to just use
> the common code? I tried very hard to make it easy for you to just
> implement a couple hooks; I can't imagine it would take more than a day
> to do it.)

Sorry for that. It seems to be good time to resolve it.
I'll work on xencomm consolidation.

-- 
yamahata

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