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: [Xen-ia64-devel] RE: [Xen-devel] [BUNDLE] Testing a simplerinter-dom

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Yang, Fred" <fred.yang@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RE: [Xen-devel] [BUNDLE] Testing a simplerinter-domain transport
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Mon, 6 Feb 2006 15:18:54 -0800
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Feb 2006 23:29:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYrACLAC44DyOH2SMyhzX4zn+iQvQAVcqRQAAFpVvAAAbecsAADE8IgAADYm9A=
Thread-topic: [Xen-ia64-devel] RE: [Xen-devel] [BUNDLE] Testing a simplerinter-domain transport
Magenheimer, Dan (HP Labs Fort Collins) wrote:
>> Since IA-64 Linux uses bigger pages
> 
> More precisely, Linux/ia64 *default configuration* uses bigger
> (default user) page sizes, but page size is configurable
> (4K, 16K, 64K, and even larger).  While
> we may have some control over page size for domain0
> (and maybe driver domains), it is unlikely we can require one
> specific page size for all guest Linux domU's.  And because
> of this, we may need to choose 4K as the lowest common
> denominator.

Today 16KB is the default in the IPF Linux distributions; that's the one
we've ended up with from various aspects. Only academic people are using
different page sizes. The issue is that a kernel with other than 16K is
not qualified for various certifications from ISVs, for example.   

You don't need to force 16K, but it's likely that IPF XenLinux needs to
use 16K in practice.   

Jun
---
Intel Open Source Technology Center

> 
> However, Rusty, this brings up another interesting point...
> Is your new idt code designed so that the page size is
> configurable?  And (wish list) any chance it can be flexible
> enough to deal with a situation where the frontend and backend
> use a different pagesize?  At least where the backend
> pagesize is greater than the frontend pagesize?
> 
> Thanks,
> Dan
> 
>> -----Original Message-----
>> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
>> Sent: Monday, February 06, 2006 2:19 PM
>> To: Yang, Fred; Magenheimer, Dan (HP Labs Fort Collins);
>> xen-devel@xxxxxxxxxxxxxxxxxxx Cc: Rusty Russell; xen-ia64-devel
>> Subject: RE: [Xen-ia64-devel] RE: [Xen-devel] [BUNDLE]
>> Testing a simplerinter-domain transport
>> 
>> Yang, Fred wrote:
>>> Dan,
>>> 
>>>> From Xen summit, isn't it to be more P2M liked approach due to
>>> consideration on driver domain and domain0 needs to get P2M for
>>> VBD/VNIF? 
>>> 
>>> Don't remember there is decision on taking Hypercall only approach
>>> and dropped P2M table lookup.  Any justification here?
>> 
>> To me having an array like x86 xenlinux is much simpler. Since IA-64
>> Linux uses bigger pages, the size of such a table should be much
>> smaller. 
>> 
>> Jun
>> 
>>> 
>>> -Fred
>>> 
>>> Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>>> (I'm sure you meant PPC *and* ia64 ;*)
>>>> 
>>>> On just a quick skim, one thing to note:
>>>> 
>>>> IIRC from the summit, domain0 and driver domains for
>>>> neither PPC nor ia64 will have a p2m lookup table so
>>>> a p2m translation will require a hypercall. So
>>>> while virt_to_machine is cheap for domains on x86,
>>>> it is not on PPC and ia64.  If HYPERVISOR_share can
>>>> take physical addresses instead of machine addresses
>>>> (with Xen doing the phys_to_machine part of the
>>>> translation), I think the code would work better
>>>> for PPC and ia64, as well as better hide the
>>>> virtual->physical->machine memory abstraction.
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel
>>> 
>>> 
>>> _______________________________________________
>>> Xen-ia64-devel mailing list
>>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-ia64-devel


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

<Prev in Thread] Current Thread [Next in Thread>