[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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.   

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.