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] [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/
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