RE: [Xen-devel] [BUNDLE] Testing a simpler inter-domain transport

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

 > > 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.
> 
> First person to implement this on a different arch wins.  I'm 
> currently
> sewing in feedback and cleanups from Hollis for PPC requirements.
> 
> Now, I think that the virt_to_machine is fugly too.  I'd 
> prefer to keep
> all archs the same though.  Ideally, the hypercall would pass virtual
> addresses and the hypervisor would figure out the machine address.  If
> you want to figure out how to do that on x86, I'll gladly use it...

On ia64 and I believe also on PPC, a guest can translate
from virtual to (pseudo)physical but only on x86 can
a guest translate from virtual to machine -- at least
without an extra hypercall.  On all three,
Xen can translate from (pseudo)physical to machine but
only on x86 can Xen translate from virtual to
(pseudo)physical. 

So it seems to me that if you "prefer to keep all archs the
same", the proper way to pass the parameters are as
(pseudo)physical addresses: the guest translates the
virtual address to a (pseudo)physical address and
Xen translates from the (pseudo)physical address to
the machine address and everybody is happy.

Hollis, is this correct for PPC?

Thanks,
Dan

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