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] calculate dom0 metaphysical load address co

On Thu, May 24, 2007 at 12:28:46PM +0200, Jes Sorensen wrote:
> Isaku Yamahata wrote:
> > On Thu, May 24, 2007 at 11:38:19AM +0200, Jes Sorensen wrote:
> > P=M will break the current grant table api. It means all of virtual
> > io device (balloon, vbd, vnif, ...) will be broken.
> > What do you think about it?
> 
> Then we have to fix it - the Linux kernel requires this, it's not
> optional. Sure it works for over simplified systems such as DIG, but
> anything moderately advanced will break.

I don't agree here.
I think fixing it with P=M requires much bigger efforts than
paravirtualizing the files under sn/ directory.
Looking around sn/ directory, I found that address conversion
functions are centralized in linux/include/asm-ia64/sn/addr.h.
It has only 295 lines. I don't think it's unrealistic to
paravirtualize them.


> > In fact, Virtual Physical address model was introduced to
> > resolve the grant table issue. And the ia64 default dma api and
> > hp zx1 iommu are already paravirtulized.
> 
> There's much more to it than that. We need it for things like
> alloc_pages_node() in the Linux kernel if we want any level of
> performance.

I'm talking about dma api paravirtualization, not NUMA.
I believe that it's feasible to support NUMA without P=M.


> I mean if we want to let individual dom's have direct access to a PCI
> device. They will need to know where in the system it's physically
> located.

It is already supported.

-- 
yamahata

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