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] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Thu, 16 Mar 2006 11:42:30 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Mar 2006 02:43:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E794F@pdsmsx403>
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: <571ACEFD467F7749BC50E0A98C17CDD8094E794F@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Wed, Mar 15, 2006 at 05:12:33PM +0800, Tian, Kevin wrote:

> >9191:2ac9130fb9f6_fix_grant_entry_t_frame.patch
> 
> This one is a fix and can be sent out to xen mailing list earlier. But it may 
> not be so urgent to see the issue for IA64 and x86-64. See how large 
> even 32bit can support: 4G * 4K = 16T. I don't think people ever tested on 
> it now. :-)

I agree. 32 bits might be sufficient for at least several years.


> >9192:80353e9e2e0f_grant_table_xen_part.patch
> >9193:6922c2fe7446_grant_table_linux_part.patch
> 
> Sorry that I didn't look into carefully, but why following logic:
> +#ifndef __ia64__
>       shared[ref].frame = frame;
> +#else
> +     shared[ref].frame = mfn_to_pfn(frame);//XXX
> +#endif
> 
> The caller already does virt_to_mfn which results a hypercall by your 
> model, and now another hypercall caused by mfn_to_pfn again. It's better 
> to make a decision whether frames passed from xenlinux is 
> pseudophysical or machine, and then just support it uniformly. You see 
> current grant table code can handle either case, differentiated by shadow 
> translated mode for x86. Though we have no shadow code for xen/ia64, 
> but that's the flag you can use to simplify changes.

I haven't cleaned up grant table api yet. 
I'm sure some clean up is necessary. This is the reason why XXX is there.
I'll work on it after getting vnif to work. 


> BTW, what's the intent of alloc_vm_area? Seems no one calls it. Also a 
> typo there:
> struct vm_struct* area;
> ...
> area = kmalloc(sizeof(area), GFP_KERNEL); which only gives you 8
> bytes. :-)

Oops thanks.
alloc_vm_area() is called by blkback, blktap, netback, tpmback, xenbus
to allocate virtual address area of xen I/O ring.
Allocating virtual address area which doesn't have corresponding
pseudo physical page is xen/x86-ism.
Some clean up is also needed.

-- 
yamahata

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