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/
Home Products Support Community News


Re: [Xen-devel] Re: user/hypervisor address space solution

On 17 Feb 2006, at 05:39, Hollis Blanchard wrote:

Should be called get_guest/put_guest/copy_from_guest/copy_to_guest. Better names, and the arch-specific old functions can still keep their old names.

I don't think I understood your full meaning before, but I'm with you now. get/put_user() will still exist on x86 and mean virtual addresses (kernel or user). The new get/put_guest_offset() implementations will be equivalent.

PowerPC will implement get/put_guest_offset(), but will not implement get/put_user() at all. If those latter calls do make their way into common code (after the PPC code has been merged), every PPC build in the regression test suite will fail, so the patch will be flagged as bad and not committed.

This sounds fine to me, other than that bit about confusing the word "user" to mean "virtual" (since it could of course be a kernel address as well).

I actually managed to get rid of get/put_user from common code, so we only need replacements for copy_to/from_user.

I suggest e.g., copy_to_guest(handle, offset, xen_ptr, nr_items)

where handle is a 'guest pointer' of type foo *, which we view as pointing at an array of foos. 'offset' is the offset into the foo array to start copying to. xen_ptr must be of type foo *; it is the start address to copy from. nr_items is the number of foos to copy.

There are a few other thgings to consider too. We could have copy_array_to_guest with the above declaration, and have a simpler copy_to_guest with no 'nr_items' parameter. We will need __copy_to_guest alternatives where the handle has been pre-validated.

How does that sound?

 -- Keir

Xen-devel mailing list