WARNING - OLD ARCHIVES

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

xen-devel

[Xen-devel] Re: [PATCH] Allow guest to register a secondary vcpu_time_in

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Allow guest to register a secondary vcpu_time_info structure
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 06 Oct 2009 09:50:29 -0700
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 06 Oct 2009 09:50:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6F0ABF3.1677E%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C6F0ABF3.1677E%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 10/06/09 00:10, Keir Fraser wrote:
> On 06/10/2009 01:10, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote:
>
>   
>> The second vcpu_time_info structure is updated by copy, rather than
>> being a shared page between the guest and Xen.  It is not directly
>> updated by copy; instead, Xen preserves and increments the existing
>> version number in place.  This allows the guest to also update the
>> version number (useful to indicate vcpu context switches to usermode).
>> This assumes that the guest will only ever update the structure for a
>> given vcpu on that vcpu (as Xen does, so there are never any cross-cpu
>> accesses).
>>     
> How do you feel about the 32-bit version number? We have space to easily
> expand it to 64 bits, and now would be the time to do it while we're
> extending the ABI.
>   

I think 32 bit (well, 31) is fine:

The version number doesn't increment that often, so I think it would
take a long time to wrap.  The only failure mode is if the version wraps
and gets an aliased value between the "get version" and "re-test
version" phases of the algorithm, which is only a few tens of
instructions at most.  I would think it unlikely the version increments
once in that period, let alone 2^31 times.  As far as I know, nobody is
keeping long-term copies of the time info.

(One unlikely scenario is that you have usermode in the middle of a
vsyscall gettimeofday when the domain gets suspended/migrated and it is
suspended for some long period of time.  But this is OK because the
version gets saved along with the rest of the domain and incremented
from there.  I'm not sure if the same applies to the shared_info
version, but that's less of a concern because the kernel will never
preempt itself doing a clocksource_read to suspend.)

Aside from that, this isn't really an ABI extension.  The registration
of the secondary vcpu_time_info is a new ABI, but from there it is
identical to the existing pvclock ABI; I use the same code for both the
kernel and in the vsyscall page, so making them different would be
awkward (of course I could change the kernel to use the "secondary" time
values too, but it would still need to support old hypervisors so it
wouldn't save anything).  KVM is also using this ABI, so I wouldn't want
to introduce an arbitrary ABI change.

Also, a >32 bit version field would be hard for 32 bit guests to deal
with; it's not easy to either read or update its value in a single
instruction. (32 bit Xen too, but I guess we're less concerned about that.)

    J

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