[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to support XEN_DOMCTL_set_rdm
Hi Kevin, Thanks for taking the time to work through this. At 03:39 +0000 on 10 Dec (1418179184), Tian, Kevin wrote: > 1. It's more efficient for new people to start from a small, well-defined task > in one area, and then spanning to adjacent areas gradually. Patience must > be given by the community to help them grow; > > 2. Unfortunately this RMRR effort grows from original two patches (very VT-d > focused) to now v8 17 patches spanning many areas (including hypercall, mmu, > domain builder, hvmloader, etc.), and thus imposing both long learning curve > and lots of frustrations being no achievement returned. Though having a > complete > solution is desired, we need to help split the big task into step-by-step > approach > as long as: > - the overall design is agreed > - each step is self-contained > - each step won't be wasted moving forward. > That way new people can see incremental achievements, instead of being hit > down before final success. > > Take this RMRR for example. Maybe we can split into steps like: > > step-1: setup RMRR identify mapping in hypervisor. fail if confliction. > no > user space changes > step-2: expose RMRR knowledge to userspace and detect confliction in > domain builder and hvmloader > step-3: reconcile e820/mmio to avoid confliction in a best effort > step-4: miscellaneous enhancements, each can be ACK-ed individually: > - handle guest CPU access to RMRR regions > - handle conflicting RMRR regions > - handle group RMRRs > - re-enable USB device assignment > > That way Tiejun can focus on a self-contained task at one time, and then > observe > continuous acknowledgements for his work. We don't need to claim RMRR fully > ready in Xen until last patch is accepted, but that at least provides a way > to ack > new people when working on complex features and also allow for partial usage > on his work. We had this discussion before and I think it was clear that the maintainers in general are unhappy with a partial solution. OTOH, if we can agree on the roadmap, and Intel will commit to seeing the work through, it might be possible. I think Jan is the man to convince here. :) Now since the code's not going to be in 4.5 anyway, it should be possible to _develop_ it in this manner, possibly in a private branch, even if the early stages aren't getting applied immediately. We should be able to set up an rmrr branch on the public servers if that helps. But again, that relies on having a design worked out in advance that both developers and maintainers are (within reason) committed to. > 3. Maintainers sometimes didn't give definitive guidance to the new people, > and the high-level design is not closed in the 1st place. e.g. when I thought > this v8 > version has everyone agreed on the design, there's another comment from Jan > about using XENMEM_set_memory_map might be better, while back to Aug. > when Tiejun raised that option the answer is "I'm not sure". Note I understand > as a maintainer he might not have definite answers for all opens. But w/o a > definitive guide new people may waste lots of effort on chasing a wrong > option, > which is definitely frustrating. This is definitely a problem, and indeed frustrating for the developers. We had similar difficulties with PVH development, where even though we planned the architecture up-front, once the code was written it became clear that a different approach would have been better. I'm not sure what we can do here to make it more likely that we get the design right first time. I do think that figuring out the design in advance makes these projects much smoother, and it's something we're seeing more of. For example David Vrabel's designs for the new event channel interface, or indeed the design doc he wrote about grant table locking, where review at the design stage may have avoided a bunch of implementation effort altogether. > So I'd suggest for such non-trivial task for a new people, all maintainers in > involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree > on the high level design. At that stage, let's skip the coding problems to > save > both time. That sounds like a very good idea to me. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |