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-ia64-devel

[Xen-ia64-devel] RE: Timer merge

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] RE: Timer merge
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 26 Aug 2005 23:08:41 +0800
Cc: "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>
Delivery-date: Fri, 26 Aug 2005 15:06:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWnjSOhSjX2nMKXQI2EGFjNgzyS+AAXrvdAAAAqXDAAAf54IAAFcXoAAATDFSAAADCbAAAOO83gAB29uYAAKFIVoAACuHFQAC2vyoAAAx/l4AAEUTKw
Thread-topic: Timer merge
>>
>> This is a bug if you want to keep a periodic HZ concept in
>> hypervisor. (Maybe we can abandon it and only keep a one-shot
>> timer model later). It's unrelated to this discussion, and
>> just raised it since mentioned in the context.
>
>I'm not sure I understand the differences between the periodic
>HZ concept and the one-shot timer model... doesn't there always
>need to be a timeout for the currently running domain so
>the hypervisor scheduler can schedule a different domain?

Sorry to put confused concept here. What I mean by "one-shot" timer here
actually mean a tick-less model where next interrupt point is always
triggered by closest timer event, without need to care fixed delta.
Current model actually keeps both. Just raise a possibility.

>
>> IMO, the extra work should at least keep a global monotonic
>> increasing variable to hold itc value at last time interrupt.
>> Then the delta value of guest itc should base on this global
>> variable, instead of local itc. When emulating read_from_itc,
>> we may return by formula like "(now_itc > monotonic_itc) ?
>> (now_itc + vitc_delta) : (monotonic_itc + vitc_delta)". This
>> can promise itc never going backward when vcpu migration. En,
>> anyway this is just some rough thought immediately raised,
>> and we definitely need elaborate and detail discussion in
>> design for vcpu migration. Currently we just need a guest ITM
>> together with ITC delta, as Eddie suggested.
>
>So in your model, reading itc is privileged?  (e.g. secure
>itc bit is on)  In the current model, it is not.

Still guest can read itc directly, as long as the global value stamped
in the shared page when injecting guest timer interrupt. Just same as
you need to export itc delta to guest too. Guest shouldn't use itc value
directly, even when it can read.

Thanks,
Kevin

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

<Prev in Thread] Current Thread [Next in Thread>