From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaM7S-0007vP-Ns for qemu-devel@nongnu.org; Tue, 24 Mar 2015 06:31:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaM7N-00036l-VT for qemu-devel@nongnu.org; Tue, 24 Mar 2015 06:31:34 -0400 Received: from mga02.intel.com ([134.134.136.20]:11955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaM7N-000369-L8 for qemu-devel@nongnu.org; Tue, 24 Mar 2015 06:31:29 -0400 Message-ID: <55113CFD.1040406@intel.com> Date: Tue, 24 Mar 2015 18:31:25 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <1427073466-16956-1-git-send-email-tiejun.chen@intel.com> <1427073466-16956-3-git-send-email-tiejun.chen@intel.com> <55112498.2040108@intel.com> <1427190704.21742.318.camel@citrix.com> <55113959.90600@intel.com> <1427192444.21742.330.camel@citrix.com> In-Reply-To: <1427192444.21742.330.camel@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Campbell Cc: Kevin , wei.liu2@citrix.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com On 2015/3/24 18:20, Ian Campbell wrote: > On Tue, 2015-03-24 at 18:15 +0800, Chen, Tiejun wrote: >> On 2015/3/24 17:51, Ian Campbell wrote: >>> On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote: >>>> All guys, >>>> >> >> Thanks for your reply. >> >>>> Sorry to bother you. >>>> >>>> I have a question to two files, tools/python/xen/lowlevel/xc/xc.c and >>>> tools/python/xen/lowlevel/xl/xl.c. Who is a caller to those methods like >>>> pyxc_methods[] and pyxl_methods[]? >>> >>> They are registered with the Python runtime, so they are called from >>> Python code. The first member of the struct is the pythonic function >> >> Sorry I don't understanding this. So seems you mean instead of xl, this >> is called by the third party user with python? > > Yes, tools/python/xen is the python bindings for various C libraries > supported by Xen. Thanks for your explanation. > > NB, the libxl ones are broken and not even compiled right now, you can > ignore them. Looks this is still compiled now. > >> >>> name, e.g. from xc.c: >>> { "domain_create", >> >> Otherwise, often we always perform `xl create xxx' to create a VM. So I >> think this should go into this flow like this, >> >> xl_cmdtable.c:main_create() >> | >> + create_domain() >> | >> + libxl_domain_create_new() >> | >> + do_domain_create() >> | >> + .... >> Right? > > Yes, xl is written in C not python so tools/python doesn't enter the > picture. Yeah. > >> >>> (PyCFunction)pyxc_domain_create, >> >> So I don't see 'pyxc_domain_create' is called. Or I'm missing something... > > Chances are that there are no intree users of this code any more, xend > would have used it at one time with something like: > import xen.lowlevel.xc > xc = xen.lowlevel.xc.xc() > xc.domain_create() > etc. > >>> >>>> In my specific case, I'm trying to introduce a new flag to each a device >>>> while assigning device. So this means I have to add a parameter, 'flag', >>>> into >>>> >>>> int xc_assign_device( >>>> xc_interface *xch, >>>> uint32_t domid, >>>> uint32_t machine_sbdf) >>>> >>>> Then this is extended as >>>> >>>> int xc_assign_device( >>>> xc_interface *xch, >>>> uint32_t domid, >>>> uint32_t machine_sbdf, >>>> uint32_t flag) >>>> >>>> After this introduction, obviously I should cover all cases using >>>> xc_assign_device(). And also I found this fallout goes into these two >>>> files. For example, here pyxc_assign_device() is involved. Currently it >>>> has two parameters, 'dom' and 'pci_str', and as I understand 'pci_str' >>>> should represent all pci devices with SBDF format, right? >>> >>> It appears so, yes. >>> >>>> But I don't know exactly what rule should be complied to construct this >>>> sort of flag into 'pci_str', or any reasonable idea to achieve my goal? >>> >>> If it is non-trivial to fix them IMHO it is acceptable for the new >>> parameter to not be plumbed up to the Python bindings until someone >>> comes along with a requirement to use it from Python. IOW you can just >>> pass whatever the nop value is for the new argument. >>> >> >> Should I extend this 'pci_str' like "Seg,bus,device,function:flag"? But >> I'm not sure if I'm breaking the existing usage since like I said, I >> don't know what scenarios are using these methods. > > Like I said in the paragraph above, if it is complicated then it is fine > to ignore this new parameter from Python. > > I don't know what the semantics of flag is, if it is per SBDF then I Yes, this should be a flag specific to a SBDF. You know, I'm working to fix RMRR completely. Based on some discussion about that design ( I assume you may read that thread previously :) ), now we probably need to pass a flag to introduce our policy. > suppose if you really wanted to expose this here then you would need to > invent some syntax for doing so. > Definitely. When I finish this I will send you to review technically. Again, really appreciate your clarification to me. Thanks Tiejun