From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings Date: Thu, 28 Aug 2014 15:09:35 +0800 Message-ID: <53FED5AF.7080803@intel.com> References: <1409050980-21933-1-git-send-email-tiejun.chen@intel.com> <1409050980-21933-4-git-send-email-tiejun.chen@intel.com> <53FC774D.8000501@citrix.com> <53FC9BB1020000780002D986@mail.emea.novell.com> <53FD3669.3070705@intel.com> <53FD9C03020000780002DEFF@mail.emea.novell.com> <53FD86E9.4020205@intel.com> <53FE92C6.6050605@intel.com> <53FEED4F020000780002E76C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53FEED4F020000780002E76C@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: kevin.tian@intel.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, Andrew Cooper , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com List-Id: xen-devel@lists.xenproject.org On 2014/8/28 14:50, Jan Beulich wrote: >>>> On 28.08.14 at 04:24, wrote: >> If you guys have no more comments, could I send a new series to review? > > You certainly can do so at any time, but as said before I didn't get > to looking at the current version yet; briefly having looked at the I knew this point so this is just why here I's like to ask if I can send new revision. I hope I can do better as you expect. > first two patches I'm already pretty convinced that the structuring > still isn't right (you shouldn't be exposing VT-d internals into If you have any comment, I think you can point inline, then I can take a look at that to improve or fix anything as you expect. As you know, I'm not familiar with Xen codes so sometimes I can't understand what you mean properly, even what you were saying. So I have to ask you to explain explicitly again. > arbitrary parts of the hypervisor, but rather introduce a new > vendor IOMMU hook/actor to get at the reserved page information > - this all still goes along the lines of you apparently not > understanding that a reasonable level of abstraction helps in the > long term maintenance of such code). If you always say I'm wrong to understand rather than show me something explicitly, its still difficult to fine such codes for a fresh man. Thanks Tiejun