Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to support XEN_DOMCTL_set_rdm

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Wednesday, December 10, 2014 7:12 PM
> 
> 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. :)

I think w/ last 8 series Tiejun has sent out, there's no doubt Intel commits
to make a complete work. :-)

> 
> 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.

that's a good suggestion. We'll send out a design review today, and then
based on discussion we can see whether making sense to do such 
incremental way.

> 
> > 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.

understand and reasonable.

> 
> 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.

yes. a formal review in advance would be lot better than mixing design 
comments in scattered in deep coding review comments. For this RMRR
example, Tiejun did send out some summary for his patch set, but not
abstracted enough to catch people's eye on key design opens. And having
a goal for 4.5 window really brought him hard time to balance code 
refactoring and learn new areas when each series was questioned with 
new design inputs.

> 
> > 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.
> 

Thanks a lot,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel