|
|
|
|
|
|
|
|
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
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
|
|
|
|
|