From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [ Help! ] how is ctx->xch in xen/tools/libxl/xl_cmdimpl.c initialized? Date: Tue, 23 Apr 2013 19:23:52 +0200 Message-ID: <1366737832.2670.44.camel@Solace> References: <20130411184106.GH5936@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2342931091208089650==" 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: Li Yechen Cc: Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============2342931091208089650== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZB4mU5ewm1DQry6Ow1VY" --=-ZB4mU5ewm1DQry6Ow1VY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-04-16 at 23:17 +0800, Li Yechen wrote: > Thank you very much! > I find the function pointer point to : > .u.privcmd.hypercall =3D &linux_privcmd_hypercall on Line 423 >=20 > [snip] >=20 > I just want to find out how xl comnand works, does it actually call > this function? > The code of Xen of this part have no any commons..It's too hard to > understand. > Ok (first, sorry for the delay), you said you're interested in what main_memset(), in xl_cmdimpl.c, end up doing at the hypervisor level, right? Up to what I can see, the call chain is this: main_memset() [tools/libxl/xl_cmdimpl.c] | --> set_memory_target() [tools/libxl/xl_cmdimpl.c] | --> xc_domain_setmaxmem() ? xc_domain_set_pod_target() [tools/libxl/= libxl.c] | --> xc_domain_setmaxmem() [tools/libxc/xc_domain.c]: domctl.cmd =3D XEN_DOMCTL_max_mem; domctl.u.max_mem.max_memkb =3D max_memkb; return do_domctl(xch, &domctl); So, here is when the hypercall is invoked (Assuming that you're interested in the path that calls xc_domain_setmaxmem, otherwise, the hypercall invoked within xc_domain_set_pod_target() is XENMEM_set_pod_target). Now, when looking for XEN_DOMCTL_max_mem, consider the reference to it that can be found in xen/common/domctl.c at (around) line 886: case XEN_DOMCTL_max_mem: { unsigned long new_max; ret =3D -EINVAL; new_max =3D op->u.max_mem.max_memkb >> (PAGE_SHIFT-10); spin_lock(&d->page_alloc_lock); /* * NB. We removed a check that new_max >=3D current tot_pages; this= means * that the domain will now be allowed to "ratchet" down to new_max= . In * the meantime, while tot > max, all new allocations are disallowe= d. */ d->max_pages =3D new_max; ret =3D 0; spin_unlock(&d->page_alloc_lock); } break; And this is it. As Wei was telling you, how the hypercall is actually issued is what the OS dependent code does with all those functions pointer you found. OTOH, when you're interested in knowing _what_ an hypercall actually does, I'd dare to recommend digging until you find the hypercall name (in this case XEN_DOMCTL_max_mem) and then grep-ing/cscope-ing it directly in the hypervisor code. Does that help? :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-ZB4mU5ewm1DQry6Ow1VY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iEYEABECAAYFAlF2w6gACgkQk4XaBE3IOsQiugCgqq8ej26hY0Y+MkyffvTRVYFb LgYAoJABtYIoY9ljAmzU2bCYMBlVYRS/ =vvTY -----END PGP SIGNATURE----- --=-ZB4mU5ewm1DQry6Ow1VY-- --===============2342931091208089650== 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 --===============2342931091208089650==--