what's inside hypercall page?

what's inside hypercall page?

[quizyjones]

[-- Attachment #1.1: Type: text/plain, Size: 2617 bytes --]

I've got the hypercall_page_initialize function as follows. As the size of each hypercall page entry is 32B and the initialize function only assigns value to the first 8B, is the remaining space empty or initialized afterwards?
static void hypercall_page_initialise_ring1_kernel(void *hypercall_page){    char *p;    int i;
    /* Fill in all the transfer points with template machine code. */
    for ( i = 0; i < (PAGE_SIZE / 32); i++ )    {        if ( i == __HYPERVISOR_iret )            continue;
        p = (char *)(hypercall_page + (i * 32));        *(u8  *)(p+ 0) = 0xb8;    /* mov  $<i>,%eax */        *(u32 *)(p+ 1) = i;        *(u16 *)(p+ 5) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */ //0x82cd        *(u8  *)(p+ 7) = 0xc3;    /* ret */    }
    /*     * HYPERVISOR_iret is special because it doesn't return and expects a     * special stack frame. Guests jump at this transfer point instead of     * calling it.     */    p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));    *(u8  *)(p+ 0) = 0x50;    /* push %eax */    *(u8  *)(p+ 1) = 0xb8;    /* mov  $__HYPERVISOR_iret,%eax */    *(u32 *)(p+ 2) = __HYPERVISOR_iret;    *(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */ //0x82cd}自动判断中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语自动选择中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语有道翻译百度翻译必应翻译谷歌翻译谷歌翻译（国内）翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 10343 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[quizyjones]

[-- Attachment #1.1: Type: text/plain, Size: 4391 bytes --]

For following hypercall page initialise code,  where would the execution jumps at syscall? How can I predict what is the execution order of "pop %r11"? Is it the fifth instruction/step? I need the order to precisely set up hooks to monitor hypercalls.
static void hypercall_page_initialise_ring3_kernel(void *hypercall_page){    char *p;    int i;
    /* Fill in all the transfer points with template machine code. */    for ( i = 0; i < (PAGE_SIZE / 32); i++ )    {        if ( i == __HYPERVISOR_iret )            continue;
        p = (char *)(hypercall_page + (i * 32));        *(u8  *)(p+ 0) = 0x51;    /* push %rcx */        *(u16 *)(p+ 1) = 0x5341;  /* push %r11 */        *(u8  *)(p+ 3) = 0xb8;    /* mov  $<i>,%eax */        *(u32 *)(p+ 4) = i;        *(u16 *)(p+ 8) = 0x050f;  /* syscall */        *(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */        *(u8  *)(p+12) = 0x59;    /* pop  %rcx */        *(u8  *)(p+13) = 0xc3;    /* ret */    }
    /*     * HYPERVISOR_iret is special because it doesn't return and expects a     * special stack frame. Guests jump at this transfer point instead of     * calling it.     */    p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));    *(u8  *)(p+ 0) = 0x51;    /* push %rcx */    *(u16 *)(p+ 1) = 0x5341;  /* push %r11 */    *(u8  *)(p+ 3) = 0x50;    /* push %rax */    *(u8  *)(p+ 4) = 0xb8;    /* mov  $__HYPERVISOR_iret,%eax */    *(u32 *)(p+ 5) = __HYPERVISOR_iret;    *(u16 *)(p+ 9) = 0x050f;  /* syscall */

From: quizy_jones@outlook.com
To: xen-devel@lists.xenproject.org
Date: Wed, 2 Mar 2016 03:50:55 +0000
Subject: [Xen-devel] what's inside hypercall page?




I've got the hypercall_page_initialize function as follows. As the size of each hypercall page entry is 32B and the initialize function only assigns value to the first 8B, is the remaining space empty or initialized afterwards?
static void hypercall_page_initialise_ring1_kernel(void *hypercall_page){    char *p;    int i;
    /* Fill in all the transfer points with template machine code. */
    for ( i = 0; i < (PAGE_SIZE / 32); i++ )    {        if ( i == __HYPERVISOR_iret )            continue;
        p = (char *)(hypercall_page + (i * 32));        *(u8  *)(p+ 0) = 0xb8;    /* mov  $<i>,%eax */        *(u32 *)(p+ 1) = i;        *(u16 *)(p+ 5) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */ //0x82cd        *(u8  *)(p+ 7) = 0xc3;    /* ret */    }
    /*     * HYPERVISOR_iret is special because it doesn't return and expects a     * special stack frame. Guests jump at this transfer point instead of     * calling it.     */    p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));    *(u8  *)(p+ 0) = 0x50;    /* push %eax */    *(u8  *)(p+ 1) = 0xb8;    /* mov  $__HYPERVISOR_iret,%eax */    *(u32 *)(p+ 2) = __HYPERVISOR_iret;    *(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int  $xx */ //0x82cd}自动判断中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语自动选择中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语有道翻译百度翻译必应翻译谷歌翻译谷歌翻译（国内）翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译 		 	   		  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 11546 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[quizyjones]

[-- Attachment #1.1: Type: text/plain, Size: 4864 bytes --]

After step by step monitoring, I get the following statistics about hypercall entries:
numbers | hypercalls | executed bytes (offset to hypercall entry)   7755 24: 0 1 3 8 a c d   6374 23: 0 1 3 4 9   3281 25: 0 1 3 8 a c d   2979 13: 0 1 3 8 a c d   2475 17: 0 1 3 8   2253 17: a c d    749 3: 0 1 3 8 a c d    655 23: 0 1 3 4 9 0 1 3 4 9    640 29: 0 1 3 8    636 29: a c d    445 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9    433 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9    414 24: 0 1 3 8 a c d 0 1 3 8 a c d    274 13: 0 1 3 8 8 a c d    129 17: d    125 17: a c    112 29: a c d 0 1 3 8    112 17: c d    105 17: a     73 24: 0 1 3 8 a c d 0 1 3 8 a c d 0 1 3 8 a c d     67 17: 0     59 17: 8 a c d     54 17: 0 1 3     53 17: 0 1     50 17: 1 3 8 a c d     46 17: 3 8 a c d     21 3: 0 1 3 8 a c d 0 1 3 8 a c d      8 33: 0 1 3 8 a c d      7 17: 1 3      6 13: 0 1 3 8 8 8 a c d      5 29: d      5 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9      4 29: a c      4 17: 3      3 17: 8 a      3 17: 8      3 17: 3 8      3 17: 1 3 8 a c      3 17: 1      2 29: 0 1 3 8 a c d      2 17: 3 8 a      2 17: 1 3 8 a      2 17: 1 3 8      1 29: c      1 29: a      1 29: 3 8 a c d      1 29: 1 3 8 a c d      1 29: 0 1      1 29: 0      1 17: 3 8 a c
From the above we can see that hypercall #17 and #29 are very irregular, with various combination occurs. Other hypercalls basically obey to the sequence of "0 1 3 8 a c d" which conforms to the content in hypercall_page_initialise function. HYPERCALL_iret is a special one as explained in the function, but it also conforms to its sequence of "0 1 3 4 9". So why would #17(do_xen_version) and #29(do_sched_op) performs irregular? They seem to be easily interrupted at any place of the hypercall entry. Besides, there is also some abnormals for #13(do_multicall) shown in bold.
From: quizy_jones@outlook.com
To: xen-devel@lists.xenproject.org
Date: Wed, 2 Mar 2016 12:44:16 +0000
Subject: Re: [Xen-devel] what's inside hypercall page?




For following hypercall page initialise code,  where would the execution jumps at syscall? How can I predict what is the execution order of "pop %r11"? Is it the fifth instruction/step? I need the order to precisely set up hooks to monitor hypercalls.
static void hypercall_page_initialise_ring3_kernel(void *hypercall_page){    char *p;    int i;
    /* Fill in all the transfer points with template machine code. */    for ( i = 0; i < (PAGE_SIZE / 32); i++ )    {        if ( i == __HYPERVISOR_iret )            continue;
        p = (char *)(hypercall_page + (i * 32));        *(u8  *)(p+ 0) = 0x51;    /* push %rcx */        *(u16 *)(p+ 1) = 0x5341;  /* push %r11 */        *(u8  *)(p+ 3) = 0xb8;    /* mov  $<i>,%eax */        *(u32 *)(p+ 4) = i;        *(u16 *)(p+ 8) = 0x050f;  /* syscall */        *(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */        *(u8  *)(p+12) = 0x59;    /* pop  %rcx */        *(u8  *)(p+13) = 0xc3;    /* ret */    }
    /*     * HYPERVISOR_iret is special because it doesn't return and expects a     * special stack frame. Guests jump at this transfer point instead of     * calling it.     */    p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));    *(u8  *)(p+ 0) = 0x51;    /* push %rcx */    *(u16 *)(p+ 1) = 0x5341;  /* push %r11 */    *(u8  *)(p+ 3) = 0x50;    /* push %rax */    *(u8  *)(p+ 4) = 0xb8;    /* mov  $__HYPERVISOR_iret,%eax */    *(u32 *)(p+ 5) = __HYPERVISOR_iret;    *(u16 *)(p+ 9) = 0x050f;  /* syscall */
自动判断中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语自动选择中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语有道翻译百度翻译必应翻译谷歌翻译谷歌翻译（国内）翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 14442 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[Juergen Gross]

On 02/03/16 15:29, quizyjones wrote:
> After step by step monitoring, I get the following statistics about
> hypercall entries:
> 
> numbers | hypercalls | executed bytes (offset to hypercall entry)
>    7755 24: 0 1 3 8 a c d
>    6374 23: 0 1 3 4 9
>    3281 25: 0 1 3 8 a c d
>    2979 13: 0 1 3 8 a c d
>    2475 17: 0 1 3 8
>    2253 17: a c d
>     749 3: 0 1 3 8 a c d
>     655 23: 0 1 3 4 9 0 1 3 4 9
>     640 29: 0 1 3 8
>     636 29: a c d
>     445 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9
>     433 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9
>     414 24: 0 1 3 8 a c d 0 1 3 8 a c d
>     274 13: *0 1 3 8 8 a c d*
>     129 17: d
>     125 17: a c
>     112 29: a c d 0 1 3 8
>     112 17: c d
>     105 17: a
>      73 24: 0 1 3 8 a c d 0 1 3 8 a c d 0 1 3 8 a c d
>      67 17: 0
>      59 17: 8 a c d
>      54 17: 0 1 3
>      53 17: 0 1
>      50 17: 1 3 8 a c d
>      46 17: 3 8 a c d
>      21 3: 0 1 3 8 a c d 0 1 3 8 a c d
>       8 33: 0 1 3 8 a c d
>       7 17: 1 3
>       6 13: 0 1 3 8 8 8 a c d
>       5 29: d
>       5 23: 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9 0 1 3 4 9
>       4 29: a c
>       4 17: 3
>       3 17: 8 a
>       3 17: 8
>       3 17: 3 8
>       3 17: 1 3 8 a c
>       3 17: 1
>       2 29: 0 1 3 8 a c d
>       2 17: 3 8 a
>       2 17: 1 3 8 a
>       2 17: 1 3 8
>       1 29: c
>       1 29: a
>       1 29: 3 8 a c d
>       1 29: 1 3 8 a c d
>       1 29: 0 1
>       1 29: 0
>       1 17: 3 8 a c
> 
> From the above we can see that hypercall #17 and #29 are very irregular,
> with various combination occurs. Other hypercalls basically obey to the
> sequence of "0 1 3 8 a c d" which conforms to the content in
> hypercall_page_initialise function. HYPERCALL_iret is a special one as
> explained in the function, but it also conforms to its sequence of "0 1
> 3 4 9". So why would #17(do_xen_version) and #29(do_sched_op) performs

do_sched_op is self explaining: it is used for scheduling of the vcpu.
A vcpu going to idle is using this hypercall. So any interrupt waking
the vcpu up will seem to occur very near to the hypercall.

do_xen_version is often used as a very fast way to execute the check
for pending events in the hypervisor (kind of polling).

> irregular? They seem to be easily interrupted at any place of the
> hypercall entry. Besides, there is also some abnormals for
> #13(do_multicall) shown in bold.

do_multicall might run for a long time. So the hypervisor returns to
the caller from time to time setting IP to the hypercall. The caller
has the chance to react to interrupts and will then continue the
hypercall.


HTH, Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[quizyjones]

[-- Attachment #1.1: Type: text/plain, Size: 2486 bytes --]

> do_sched_op is self explaining: it is used for scheduling of the vcpu.
> A vcpu going to idle is using this hypercall. So any interrupt waking
> the vcpu up will seem to occur very near to the hypercall.

> do_xen_version is often used as a very fast way to execute the check
> for pending events in the hypervisor (kind of polling).

> do_multicall might run for a long time. So the hypervisor returns to
> the caller from time to time setting IP to the hypercall. The caller
> has the chance to react to interrupts and will then continue the
> hypercall.
> 
> 
> HTH, Juergen


Thanks for the replying. Does that mean we cannot predict when will these two hypercalls finish? I want to set up an interval to monitor the instructions (one time monitor per hypercall), so as to reduce the performance cost. This requires an accurate prediction of instructions' execution so as to avoid missing hypercalls. Is that possible? The main problem is the execution of syscall (0x050f), as each hypercall behaves different, how can I predict where will it go after the syscall returns?
自动判断中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语自动选择中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语有道翻译百度翻译必应翻译谷歌翻译谷歌翻译（国内）翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 9577 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[Juergen Gross]

On 03/03/16 01:56, quizyjones wrote:
>> do_sched_op is self explaining: it is used for scheduling of the vcpu.
>> A vcpu going to idle is using this hypercall. So any interrupt waking
>> the vcpu up will seem to occur very near to the hypercall.
> 
>> do_xen_version is often used as a very fast way to execute the check
>> for pending events in the hypervisor (kind of polling).
> 
>> do_multicall might run for a long time. So the hypervisor returns to
>> the caller from time to time setting IP to the hypercall. The caller
>> has the chance to react to interrupts and will then continue the
>> hypercall.
>>
>>
>> HTH, Juergen
> 
> 
> Thanks for the replying. Does that mean we cannot predict when will
> these two hypercalls finish? I want to set up an interval to monitor the
> instructions (one time monitor per hypercall), so as to reduce the
> performance cost. This requires an accurate prediction of instructions'
> execution so as to avoid missing hypercalls. Is that possible? The main
> problem is the execution of syscall (0x050f), as each hypercall behaves
> different, how can I predict where will it go after the syscall returns?

You can't predict how long a hypercall will run, as this depends on multiple
factors, like the overall load of the host, values of parameters, ...

A hypercall is by it's nature much more complicated than e.g. a simple
arithmetic operation.

What exactly do you want to achieve?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[quizyjones]

[-- Attachment #1.1: Type: text/plain, Size: 3837 bytes --]

What I want to do is predict how many instructions a hypercall entry of hypercall page (not hypercall handler) would execute before it finishes. Take HYPERVISOR_iret as an example, it precisely executes five instructions then call the hypercall handler, and it doesn't return so it just finish. But other hypercall entries expect a return value of syscall and might be interrupted during the execution, just as what you said about do_sched_up and do_xen_version, so it is hard to predict. Is there any solution to this problem? Just like syscall table, how can I predict how many instructions the syscall entries would execute before it actually go to the handler, thus accurately set traps to the syscall?

> Subject: Re: [Xen-devel] what's inside hypercall page?
> To: quizy_jones@outlook.com; xen-devel@lists.xenproject.org
> From: jgross@suse.com
> Date: Thu, 3 Mar 2016 06:28:06 +0100
> 
> On 03/03/16 01:56, quizyjones wrote:
> >> do_sched_op is self explaining: it is used for scheduling of the vcpu.
> >> A vcpu going to idle is using this hypercall. So any interrupt waking
> >> the vcpu up will seem to occur very near to the hypercall.
> > 
> >> do_xen_version is often used as a very fast way to execute the check
> >> for pending events in the hypervisor (kind of polling).
> > 
> >> do_multicall might run for a long time. So the hypervisor returns to
> >> the caller from time to time setting IP to the hypercall. The caller
> >> has the chance to react to interrupts and will then continue the
> >> hypercall.
> >>
> >>
> >> HTH, Juergen
> > 
> > 
> > Thanks for the replying. Does that mean we cannot predict when will
> > these two hypercalls finish? I want to set up an interval to monitor the
> > instructions (one time monitor per hypercall), so as to reduce the
> > performance cost. This requires an accurate prediction of instructions'
> > execution so as to avoid missing hypercalls. Is that possible? The main
> > problem is the execution of syscall (0x050f), as each hypercall behaves
> > different, how can I predict where will it go after the syscall returns?
> 
> You can't predict how long a hypercall will run, as this depends on multiple
> factors, like the overall load of the host, values of parameters, ...
> 
> A hypercall is by it's nature much more complicated than e.g. a simple
> arithmetic operation.
> 
> What exactly do you want to achieve?
> 
> 
> Juergen
> 
自动判断中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语自动选择中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语有道翻译百度翻译必应翻译谷歌翻译谷歌翻译（国内）翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 11095 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: what's inside hypercall page?

[Juergen Gross]

On 03/03/16 08:09, quizyjones wrote:
> What I want to do is predict how many instructions a hypercall entry of
> hypercall page (not hypercall handler) would execute before it finishes.
> Take HYPERVISOR_iret as an example, it precisely executes five
> instructions then call the hypercall handler, and it doesn't return so
> it just finish. But other hypercall entries expect a return value of
> syscall and might be interrupted during the execution, just as what you
> said about do_sched_up and do_xen_version, so it is hard to predict. Is
> there any solution to this problem? Just like syscall table, how can I
> predict how many instructions the syscall entries would execute before
> it actually go to the handler, thus accurately set traps to the syscall?

Just look at the code? It's not magic, just x86 instructions. In case of
interrupts
the interrupted code is normally resumed where the interrupt occurred.
So the
number of instructions executed in the hypercall page per hypercall is
just the
number of instructions you can see for that specific hypercall. Only
exception
is the case where the call into the hypervisor itself (syscall) may be
repeated
on request of the hypervisor (do_multicall_op).

Juergen

BTW: Please don't top-post.

> 
>> Subject: Re: [Xen-devel] what's inside hypercall page?
>> To: quizy_jones@outlook.com; xen-devel@lists.xenproject.org
>> From: jgross@suse.com
>> Date: Thu, 3 Mar 2016 06:28:06 +0100
>>
>> On 03/03/16 01:56, quizyjones wrote:
>> >> do_sched_op is self explaining: it is used for scheduling of the vcpu.
>> >> A vcpu going to idle is using this hypercall. So any interrupt waking
>> >> the vcpu up will seem to occur very near to the hypercall.
>> >
>> >> do_xen_version is often used as a very fast way to execute the check
>> >> for pending events in the hypervisor (kind of polling).
>> >
>> >> do_multicall might run for a long time. So the hypervisor returns to
>> >> the caller from time to time setting IP to the hypercall. The caller
>> >> has the chance to react to interrupts and will then continue the
>> >> hypercall.
>> >>
>> >>
>> >> HTH, Juergen
>> >
>> >
>> > Thanks for the replying. Does that mean we cannot predict when will
>> > these two hypercalls finish? I want to set up an interval to monitor the
>> > instructions (one time monitor per hypercall), so as to reduce the
>> > performance cost. This requires an accurate prediction of instructions'
>> > execution so as to avoid missing hypercalls. Is that possible? The main
>> > problem is the execution of syscall (0x050f), as each hypercall behaves
>> > different, how can I predict where will it go after the syscall returns?
>>
>> You can't predict how long a hypercall will run, as this depends on
> multiple
>> factors, like the overall load of the host, values of parameters, ...
>>
>> A hypercall is by it's nature much more complicated than e.g. a simple
>> arithmetic operation.
>>
>> What exactly do you want to achieve?
>>
>>
>> Juergen
>>
> 翻译朗读复制正在查询，请稍候……重试朗读复制复制朗读复制via 译


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel