RE: [Xen-devel] FYI: userland <-> hypervisor parameter passing

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> From previous conversations, I understand that the x86-64 
> hypervisor runs in a separate virtual address space. However, 
> due to the layout of the x86 page tables, it's relatively 
> straightforward (though not ideal) to walk the page tables 
> and perform the translation in software. The approach taken 
> in this patch may speed up the translation currently done on 
> x86-64, or it may not.

That's not actually the case -- the hypervisor shares an address space
with the kernel.

However, for VT/Pacifica (hvm) domains the hypervisor is in a separate
address space. Thus, there are similar issues with paravirtualized
device drivers calling into the hypervisor within hvm domains. 
 
> This translation is currently only done for 
> dom0_op and memory_op hcalls, which are the offenders I've 
> run into so far.

In the hvm paravirt driver case its memory and grant table ops that we
need to call from the kernel. This is handled by pre-registering the
memory and avoiding external references. Even so, current patches aint
pretty yet, though I think they can be made so.

It's dom0 ops that really cause the problems because of the wide use of
pass-by-ptr. Since they're typically non performance critical, it makes
me wander whether we should treat them differently. Just how slow is
looking up a virtual address on power?

> [Side note: "domctrl" is a custom domain builder we're using 
> because libxc needs some portability love that nobody seems 
> interested in at the moment (probably justifiably so). 

Yeah, this isn't the time to crack things open -- that's why we've been
pushing back on the paravirt driver patches. Early in 3.1 we'd better
have figured this out...

Ian

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