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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
From: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
Date: Fri, 07 Jul 2006 18:59:12 +0900
Delivery-date: Fri, 07 Jul 2006 03:00:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: (Your message of "Fri, 7 Jul 2006 16:01:47 +0800") <386718549BA50E498DA75F3C0518CEEC0F1F60@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <386718549BA50E498DA75F3C0518CEEC0F1F60@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Kevin

Thank you for your comments.

I agree your points.
I will change it as your comments.

Anyway, I should change the name of function(vcpu_get_next_timer),
because the meaning is changed.:-)

Thanks,
Atsushi SAKAI




 
>>From: Atsushi SAKAI [mailto:sakaia@xxxxxxxxxxxxxx]

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


------------------------------------------------------------
富士通(株) プラットフォーム技術開発本部 仮想システム開発統括部
酒井 敦    Email   sakaia@xxxxxxxxxxxxxx
                TEL     7124-4167(4月7日より)




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