Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/9] Add cpu idle pwr mgmt to xen
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 30 Apr 2008 11:00:23 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 30 Apr 2008 03:01:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D9219@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciqpXdFIt+C8IwQS7OhFvTNNKD8/gAABqMgAADb5q4=
Thread-topic: [Xen-devel] [PATCH 1/9] Add cpu idle pwr mgmt to xen
User-agent: Microsoft-Entourage/11.4.0.080122
On 30/4/08 10:42, "Tian, Kevin" <kevin.tian@xxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel