RE: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 5/5] changes of commonfiles for xen/ia64 dom0 vp model: netback work around

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Since Isaku hasn't answered yet, I'll comment: 

> Does netback work *at all* for you with vp model? Looks like 
> this patch 
> may make it build but not actually work, which makes it seem a bit 
> pointless.

With a full set of Isaku's VP patches, netfront/netback works
(and is fast)!  Because the patches affect many components
both in archdep and arch-independent code, Isaku is trying
to phase them in so Xen/ia64 continues to work in the interim.
 
> Anyway, two possible solutions are apparent to me:
>   1. netback gathers 'transmitted' skbuffs and then, in one 
> batch, does 
> a populate_physmap() call to get new pages for all of them, the 
> kfree_skb()s each one back to system pool.
>   2. change semantics of grant transfers for vp guests so that the 
> operation automatically gets you a fresh page at the same 
> pseudo-physical address.
> 
> Option (2) is maybe the better one? Then this patch would make more 
> sense (except that the code would be made run-time dependent on 
> autotranslate feature flag).

One critical concern for Xen/ia64 is that we must be very careful
when the mapping from pseudo-physical address to machine address
changes, since the hardware-walked page table (VHPT) maps
virtual to machine and flushing the entire VHPT is horribly
expensive.  There are some ideas for tracking the mappings, but
these are still being worked out.

If tracking or flushing proves to be too expensive (on average),
copying may prove more efficient than page-flipping.

Isaku can provide more info.

Dan

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