From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaZy4-0007oe-Ei for qemu-devel@nongnu.org; Tue, 24 Mar 2015 21:18:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaZy1-0001am-6q for qemu-devel@nongnu.org; Tue, 24 Mar 2015 21:18:48 -0400 Received: from mga03.intel.com ([134.134.136.65]:23923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaZy1-0001aY-0M for qemu-devel@nongnu.org; Tue, 24 Mar 2015 21:18:45 -0400 Message-ID: <55120CEA.2020607@intel.com> Date: Wed, 25 Mar 2015 09:18:34 +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> <55113CFD.1040406@intel.com> <1427193616.21742.333.camel@citrix.com> In-Reply-To: <1427193616.21742.333.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:40, Ian Campbell wrote: > On Tue, 2015-03-24 at 18:31 +0800, Chen, Tiejun wrote: >>> NB, the libxl ones are broken and not even compiled right now, you can >>> ignore them. >> >> Looks this is still compiled now. > > xc is, xl is not, I am sure of that. Indeed, you're right :) > >>> 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. > > Unless you have a concrete requirement to expose RMRR via the Python > bindings to libxc (i.e. you know somebody is using them) then I think > you should not bother. Actually my problem is that, I need to add a new parameter, 'flag', like this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools can't be compiled successfully. Or maybe you're suggesting I may isolate this file while building tools, right? > > Making RMRR work via the (C) interface to libxl used by xl and libvirt > is sufficient for a new in tree feature. Yeah. Thanks Tiejun > > Ian. >>> 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 > > >