Re: [PATCH 1/9] Add cpu idle pwr mgmt to xen

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 30/4/08 10:42, "Tian, Kevin" <kevin.tian@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