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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote:
> > > > On 08.12.16 at 22:54, <dario.faggioli@xxxxxxxxxx> wrote:
> > Yeah, that was what was puzzling me too. Keeping them ordered has
> > the
> > nice property that if a user says the following in a config file:
> > 
> >  vcpuclass=["0-3:class0", "4-7:class1"]
> > 
> > (assuming that class0 and class1 are the always available Xen
> > names) it
> 
> This, btw, is another aspect I think has a basic problem: class0 and
> class1 say nothing about the properties of a class, and hence are
> tied to one particular host.
>
The other way round, I'd say. I mean, since they say nothing, they're
_not_ host specific?

Anyway, naming was another thing on which the debate was not at all
closed, but the point is exactly the one you're making here, in fact...

>  I think class names need to be descriptive
> and uniform across hosts. That would allow migration of such VMs as
> well as prevent starting them on a host not having suitable hardware.
> 
...what George suggested (but please, George, when back, correct me if
I'm misrepresenting your ideas :-)) that:
 - something generic, such as class0, class1 will always exist (well, 
   at least class0). They would basically constitute the Xen interface;
 - toolstack will accept more specific names, such as 'big' and 
   'little', and also 'A57' and 'A43' (I'm making up the names), etc.
 - a VM with vCPUs in class0 and class1 will always be created and run 
   on any 2 classes system; a VM with big and little vCPUs will only 
   run on an ARM big.LITTLE incarnation; a VM with A57 and A43 vCPUs 
   will only run on an host that has at least one A57 and one A43 
   pCPUs.

What's not clear to me is how to establish:
 - the ordering among classes;
 - the mapping between Xen's neuter names and the toolstack's (arch) 
   specific ones.

All this being said, yes, if one specify more than one class and
there's only one, as well as if one specify a class that does not
exist, we should abort domain creation. I shall add this to the specs
(it was covered in the thread, I just forgot).

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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