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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.12.14 at 04:39, <kevin.tian@xxxxxxxxx> 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;

Yes. But if a large item like the RMRR one is being picked, this is a
recipe for failure.

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

If only this wouldn't result in regressions when done in steps (like you
outlined above, or likely also if split up in any other ways). Having to
do this in one go is the price you/we have to pay for this not having
got done properly from the beginning.

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

Main problem being that the maintainers to help here are primarily you,
and only then me or others - after all this is a VT-d only problem, not a
general IOMMU one. The fact that non-VT-d code gets touched doesn't
matter when considering just the design. And that's why I had asked
Tiejun to work with the two of you on getting the basis right. I don't
know how much of that possibly happened without the public seeing it,
but the results seem to suggest not all that much.

> 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. After agreed design, then we can help the new people to improve 
> the coding to reach check-in criteria, which then becomes a converging 
> process.
> 
> for this RMRR issue, let's close the design first, and then use staged 
> approach
> to get this patch series in.

Yes please. Till now (as said many times before) the only route I see
without grounds up design considerations is to disable pass-through for
devices associated with RMRRs. The longer the current situation lasts,
the more I'm tempted to put together a patch to do just that.

Jan

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