| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] FYI: userland <-> hypervisor parameter passing
> 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
|
|
|
| |
|
Home