[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings
On 2014/8/28 15:09, Chen, Tiejun wrote: On 2014/8/28 14:50, Jan Beulich wrote:On 28.08.14 at 04:24, <tiejun.chen@xxxxxxxxx> 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 theI 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 intoIf 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 As I remember you or Andrew told me not to use acpi_rmrr_units directly, instead I previously introduced a new array to store such RMRR info. Current first two patches are just introduced from you and Andrew's comments. Thanks Tiejun 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |