[xen-ppc-devel is on CC just for info]
I am porting xen-ppc's xencomm to xen/ia64.
Currently on xen/ia64 copy_from/to_guest uses guest virtual address. This
works well as long as the virtual addresses are in the TLB. When not in TLB
(or vTLB) the hypercall can't success without domain help. The possible
solution is either to touch the memory areas before doing the hypercall
and/or restarting the hypercall.
Touching the memory area is an hack and we can't be sure it works.
Restarting the hypercall is not always possible (some hypercalls are atomic:
DOM0_SHADOW_CONTROL_OP_CLEAN) or can result in a live-lock.
The most simple solution is to use guest physical addresses instead of virtual
For hypercalls directly issued by the kernel, the translation is very easy.
For hypercalls (indirectly) issued by dom0 though the ioctl, kernel has to do
the translation. Because it may not be linear in guest physical memory the
parameter is a pointer to a list of page (xencomm).
The pros of such approach is simplicity and reliability.
The main cons is maybe speed. Hopefully the most frequent hypercalls (dom0vp
and eoi) either don't use in memory parameters (dom0vp) or may be modified so
that they pass parameters through registers (eoi). IMHO speed won't be
Access to guest memory is also performed during vcpu_translate (to read vhpt)
or EFI/PAL/SAL calls. We can either do not change that code (ie both
mechanisms are not exclusive) or change the code. This point will be
Comments are welcome (I won't work tomorrow, so you have more time).
If we agree on using xencomm we will have to work with xen/ppc people in order
not to duplicate the code. Hopefully it is rather small. I have enhanced
the xencomm code so that the kernel may not use xencomm area but pass the
guest physical address with a flag to know the space is linear in memory.
At this time I can boot dom0 with xencomm. I will publish the patch later.
Xen-ppc-devel mailing list