From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: How the pv guest responds hypercall_create_continuation ? Date: Thu, 23 May 2013 09:49:47 +0100 Message-ID: <519DD82B.3080208@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7788172207690795171==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Xinxin Jin Cc: "Xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============7788172207690795171== Content-Type: multipart/alternative; boundary="------------070707000205020607000306" --------------070707000205020607000306 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On 23/05/13 01:03, Xinxin Jin wrote: > Hi all, > > In Xen's hypercall handler, sometimes when -EAGAIN error happens, Xen > will call a function hypercall_create_continuation(), which writes the > arguments of this hypercall to guest user registers. I guess the > purpose of this function is to indicate guest to try the failed > hypercall again, right ? Then I looked at guest Linux's code and try > to find the interface: > > A typical guest hypercall calling routine is (take > HYPERVISOR_mmu_update for example): > > static inline int > HYPERVISOR_mmu_update( > mmu_update_t *req, int count, int *success_count, domid_t domid) > { > return _hypercall4(int, mmu_update, req, count, success_count, domid); > } > > Then _hypercall4 will call corresponding code in hypercall_page and > return. But where is the interface with > hypercall_create_continuation()? How the guest knows it needs to try > the hypercall again? > > Thanks a lot, > > > Xinxin The whole point of hypercall continuations is to reduce the time spent in the hypervisor without processing softirqs/events etc. Therefore, long running hypercall operations create continuations, allowing a small chunk of work to be done now, and the next chunk of work to be done when the VCPU is next scheduled, which might be right afterwards but might be in a long times time. The mechanism for creating a continuation is to store the intermediate state in the guest registers and subtract 2 from the guests EIP, causing it to re-execute the int 0x82/sysenter/syscall instruction when next scheduled. ~Andrew --------------070707000205020607000306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 23/05/13 01:03, Xinxin Jin wrote:
Hi all, 

In Xen's hypercall handler, sometimes when -EAGAIN error happens, Xen will call a function hypercall_create_continuation(), which writes the arguments of this hypercall to guest user registers. I guess the purpose of this function is to indicate guest to try the failed hypercall again, right ? Then I looked at guest Linux's code and try to find the interface:

A typical guest hypercall calling routine is (take HYPERVISOR_mmu_update for example):

static inline int
HYPERVISOR_mmu_update(
    mmu_update_t *req, int count, int *success_count, domid_t domid)
{
    return _hypercall4(int, mmu_update, req, count, success_count, domid);
}

Then _hypercall4 will call corresponding code in hypercall_page and return. But where is the interface with hypercall_create_continuation()? How the guest knows it needs to try the hypercall again?

Thanks a lot,


Xinxin

The whole point of hypercall continuations is to reduce the time spent in the hypervisor without processing softirqs/events etc.

Therefore, long running hypercall operations create continuations, allowing a small chunk of work to be done now, and the next chunk of work to be done when the VCPU is next scheduled, which might be right afterwards but might be in a long times time.

The mechanism for creating a continuation is to store the intermediate state in the guest registers and subtract 2 from the guests EIP, causing it to re-execute the int 0x82/sysenter/syscall instruction when next scheduled.

~Andrew
--------------070707000205020607000306-- --===============7788172207690795171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7788172207690795171==--