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

RE: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU

To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 7 Jul 2006 16:01:47 +0800
Delivery-date: Fri, 07 Jul 2006 01:02:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AcahlxWXkq16Wpc9TcixLQcq4nd6jQAAVXbw
Thread-topic: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
>From: Atsushi SAKAI [mailto:sakaia@xxxxxxxxxxxxxx]
>Sent: 2006年7月7日 15:27
>Hi, Kevin
>
>Sorry for late, my mail sorting was failed.
>Thanks for your comments.
>
>Anyway, I reply as follows (2items)
>
>1)mITC vITC relation in GuestOS
>
>At ParaVM GuestOS, it uses real mITC as vITC(=mITC).
>See the below(Compare the ParaVM and the FullVM)
> [...]

Yes, your observation is correct which is the current design. Later 
Same drift concept will be also required for para domain on itc drift 
platform or migration.

What I meant here is not the difference between vITM and mITM. 
Currently there're two cases to manipulate machine ITM register. 
One path is to emulate write to cr.itm for para-domain with value 
saved in domain_itm. Another is used to drive soft timer with value 
saved in itm_next. That's why vcpu_set_next_time needs to choose 
the minimal value between them, to ensure timely interrupt delivery.

However let's see your case. When para-domain is doing pal_halt_light, 
you just need to register a soft time with expiration as (domain_itm - 
current ITC) since this soft timer only serves to trigger virtual time 
interrupt for target domain. It's unnecessary to set it as (itm_next - 
current ITC) when itm_next<domain_itm, since we know vcpu timer 
not expired in this case for most time. No correctness issue, and just 
hope no waste here.

Hope clearer now. :-)

Thanks,
Kevin

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