On 30/4/08 10:42, "Tian, Kevin" <kevi...@intel.com> wrote:
What do you mean by partly copying things? For a 32-on-64 guest,
all pointers from guest are 32-bit and compat_handler_okay already
ensures compat pointers validity. Only native structure may have
64-bit pointer field, which is checked by common guest_handle_okay
if from a 64bit guest, or is trusted by increasing addr limitation if
from compat layer...
Yes, I don't think we do partial copying anywhere right now. If we did, we
could apply guest_handle_okay() checks explicitly before removing the
addr-space limitation.
static pre-allocation used currently also avoids spurious failures of
hypercalls (there may be deterministic failures if the combined set
of indirect hypercall arguments exceeds the pre-allocation size.
That's also the limitation of current approach by pre-defined size, which
is not scalable if 2nd level pointer are variable decided by some count
field.
Also the approaches are not mutually exclusive. We can still have a per-vcpu
pre-alloc'ed page for most hypercalls, and allow dynamic allocation for
hypercalls which require more space and which then have to tolerate ENOMEM
failure. The pre-alloc'ed pages would no longer require to be mapped in a
special place.
On the other hand, I don't think we have any hypercall right now where 4kB
is likely to be too little space, and where the hypercall cannot be
sub-divided into smaller chunks by the compat shim.
*But* having a way to flag that arguments have been copied would also be
useful for HVM compat shims too. We already have such a flag
(guest_handles_in_xen_space) there, so we would increase commonality. This
probably means we will go down this route for PV guests too when we merge
some of the compat shim mechanisms for PV and HVM guests.
-- Keir
20 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH 1/9] Add cpu i...
.patch