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

[Tim Deegan <tim@xxxxxxx>]

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