Xen devel - Feb 2006 - RE: [Xen-ia64-devel] RE: [BUNDLE] Testing a simplerinter-domain transport

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

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@intel.com] 
> Sent: Monday, February 06, 2006 2:19 PM
> To: Yang, Fred; Magenheimer, Dan (HP Labs Fort Collins); 
> xen-devel@lists.xensource.com
> 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@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> > 
> > _______________________________________________
> > Xen-ia64-devel mailing list
> > Xen-ia64-devel@lists.xensource.com
> > http://lists.xensource.com/xen-ia64-devel
> 
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 2006-02-06 at 14:53 -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> 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?
It''s entirely independent.  The domain says "send/receive the
following
address,length pairs to/from this peer".  Now, if the hypervisor is
going to page-swap, then they''re going to need to be page-aligned for
both, but the hypervisor is certainly not required to flip pages.  My
current implementation simply does a memcpy.

Cheers,
Rusty.
-- 
 ccontrol: http://ozlabs.org/~rusty/ccontrol


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