Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

CC'ing Julien.

On Wed, 1 Mar 2017, Dario Faggioli wrote:
> On Wed, 2017-03-01 at 02:05 +0200, Anastassios Nanos wrote:
> > On Wed, Dec 7, 2016 at 8:29 PM, Dario Faggioli
> > <dario.faggioli@xxxxxxxxxx> wrote:
> > > 
> > > % Heterogeneous Multi Processing Support in Xen
> > > % Revision 1
> > > 
> > > [...]
> > Hi all,
> > 
> Hello,
> 
> > We are sending a branch[1] for comments on an initial implementation
> > of the above design document. Essentially it targets the ARM
> > big.LITTLE architecture. 
> >
> W00t ?!?! Just the fact that you did this, it is just great... thanks
> for that.

Yes, thank you for your work!


> > It would be great if you guys could comment
> > on the changes and provide some guidance for us to get it upstream.
> > 
> I'm sure up for that. I already know I won't have time to look at it
> until next week. But I'll make some space to look at the code then (I'm
> travelling, so I won't be furiously doing my own development anyway).
> 
> > We have tested it on an odroid xu4 [2] and we are able to boot guests
> > with mixed vcpu affinities (big and LITTLE).
> > 
> Great to hear this too.
> 
> > We are more than happy to submit patches once we address the issues
> > and come up with a review-able version of this implementation.
> > 
> Sure. So, from just a very quick glance, I can see an unique giant
> commit. This is ok for now, and I will look at it as it is.
> 
> But, for sure, the first step toward making things reviewable, is to
> split the big patch in a series of smaller patches, as you probably
> know yourself already. :-)
> 
> Since you're touching different component (as in, hypervisor,
> toolstack, build system, etc), splitting at the component boundaries is
> quite often something we want and ask for.
> 
> Another criteria, orthogonal to the one cited above, is to separate
> patches that change architecture specific code, from patches that
> touches common areas.
> 
> But, in general, the principle to follow is to split the patches at the
> "logical boundary", as this tries to explain:
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Break_down_your_patches

It would also be nice if you could summarize the design, and the main
architectural choices, in your introductory 0/N patch.

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