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

[Anastassios Nanos]

On Wed, Dec 7, 2016 at 8:29 PM, Dario Faggioli
 wrote:
> % Heterogeneous Multi Processing Support in Xen
> % Revision 1
>
> \clearpage
>
> # Basics
>
>  
>  Status: **Design Document**
>
> Architecture(s): x86, arm
>
>Component(s): Hypervisor and toolstack
>  
>
> # Overview
>
> HMP (Heterogeneous Multi Processing) and AMP (Asymmetric Multi Processing)
> refer to systems where physical CPUs are not exactly equal. It may be that
> they have different processing power, or capabilities, or that each is
> specifically designed to run a particular system component.
> Most of the times the CPUs have different Instruction Set Architectures (ISA)
> or Application Binary Interfaces (ABIs). But they may *just* be different
> implementations of the same ISA, in which case they typically differ in
> speed, power efficiency or handling of special things (e.g., erratas).
>
> An example is ARM big.LITTLE, which in fact, is the use case that got the
> discussion about HMP started. This document, however, is generic, and does
> not target only big.LITTLE.
>
> What need proper Xen support are systems and use cases where virtual CPUs
> can not be seamlessly moved around all the physical CPUs. In fact, in these
> cases, there must be a way to:
>
> * decide and specify on what (set of) physical CPU(s), each vCPU can execute 
> on;
> * enforce that a vCPU that can only run on a certain (set of) pCPUs, is never
>   actually run anywhere else.
>
> **N.B.:** it is becoming common to refer as AMP or HMP also to systems which
> have various kind of co-processors (from crypto engines to graphic hardware),
> integrated with the CPUs on the same chip. This is not what this design
> document is about.
>
> # Classes of CPUs
>
> A *class of CPUs* is defined as follows:
>
> 1. each pCPU in the system belongs to a class;
> 2. a class can consist of one or more pCPUs;
> 3. each pCPU can only be in one class;
> 4. CPUs belonging to the same class are homogeneous enough that a virtual
>CPU that blocks/is preempted while running on a pCPU of a class can,
>**seamlessly**, unblock/be scheduler on any pCPU of that same class;
> 5. when a virtual CPU is associated with a (set of) class(es) of CPUs, it
>means that the vCPU can run on all the pCPUs belonging to the said
>class(es).
>
> So, for instance, in architecture Foobar two classes of CPUs exist, class
> foo and class bar. If a virtual CPU running on a CPU 0, which is of class
> foo, blocks (or is preempted), it can, when it unblocks (or is selected by
> the scheduler to run  again), run on CPU 3, still of class foo, but not on
> CPU 6, which is of class bar.
>
> ## Defining classes
>
> How a class is defined, i.e., what are the specific characteristics that
> determine what CPUs belong to which class, is highly architecture specific.
>
> ### x86
>
> There is no HMP platform of relevance, for now, in x86 world. Therefore,
> only one class will exist, and all the CPUs will be set to belong to it.
> **TODO X86:** is this correct?
>
> ### ARM
>
> **TODO ARM:** I know nothing about what specifically should be used to
> form classes, so I'm deferring this to ARM people.
>
> So far, in the original thread the following ideas came up (well, there's
> more, but I don't know enough of ARM to judge what is really relevant about
> this topic):
>
> * 
> [Julien](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02153.html)
>   "I don't think an hardcoded list of processor in Xen is the right solution.
>There are many existing processors and combinations for big.LITTLE so it
>will nearly be impossible to keep updated."
> * 
> [Julien](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02256.html)
>   "Well, before trying to do something clever like that (i.e naming "big" and
>   "little"), we need to have upstreamed bindings available to acknowledge the
>   difference. AFAICT, it is not yet upstreamed for Device Tree and I don't
>   know any static ACPI tables providing the similar information."
> * 
> [Peng](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02194.html)
>   "For how to differentiate cpus, I am looking the linaro eas cpu topology 
> code"
>
> # User details
>
> ## Classes of CPUs for the users
>
> It will be possible, in a VM config file, to specify the (set of) class(es)
> of each vCPU. This allows creating HMP VMs.
>
> E.g., on ARM, it will be possible to create big.LITTLE VMs which, if run on
> big.LITTLE hosts, could leverage the big.LITTLE support of the guest OS kernel
> and tools.
>
> For such purpose, a new option will be added to xl config file:
>
> vcpus = "8"
> vcpuclass = ["0-2:class0", "3,4:class1,class3", "5:class0, class2", 
> "8:class4"]
>
> with the following meaning:
>
> * vCPUs 0, 1, 2 can only run on pcpus of class class0
> * vCPUs 3, 4 can run on pcpus of class class1 **and** on 

Re: [Xen-devel] Next Xen ARM community call

[Anastassios Nanos]

Hi Julien, Stefano, all

please add the big.LITTLE discussion to the agenda, as we're in the
process of cleaning up and sending a branch for initial comments. I'm
adding Thanasis Katsios in CC, the main contributor.

I might not be able to join the call, but Thanasis will be around.

cheers,
A.

On Tue, Feb 28, 2017 at 3:29 PM, Julien Grall  wrote:
> Hi,
>
> I haven't seen any complain with the time suggested by Stefano. So the
> Community call will be at 5pm UTC tomorrow (Wednesday 1st March).
>
> Regarding the agenda, the topics I have so far are:
> - PV protocols
> - IRQ latency
>
> Do we have any other topics to discuss?
>
> For joining the call, please use either:
>
> Call+44 1223 406065 (Local dial in)
> and enter the access code below followed by # key.
> Participant code: 4915191
>
> Mobile Auto Dial:
> VoIP: voip://+441223406065;4915191#
> iOS devices: +44 1223 406065,4915191 and press #
> Other devices: +44 1223 406065x4915191#
>
> Additional Calling Information:
>
> UK +44 1142828002
> US CA +1 4085761502
> US TX +1 5123141073
> JP +81 453455355
> DE +49 8945604050
> NO +47 73187518
> SE +46 46313131
> FR +33 497235101
> TW +886 35657119
> HU +36 13275600
> IE +353 91337900
>
> Toll Free
>
> UK 0800 1412084
> US +1 8668801148
> CN +86 4006782367
> IN 0008009868365
> IN +918049282778
> TW 08000 22065
> HU 0680981587
> IE 1800800022
> KF +972732558877
>
> Regards,
>
>
>
> On 17/02/17 15:00, Julien Grall wrote:
>>
>> Hi Stefano,
>>
>> On 16/02/17 18:40, Stefano Stabellini wrote:
>>>
>>> On Thu, 16 Feb 2017, Julien Grall wrote:

 Hello,

 The last two community calls went really good and I am suggesting to
 have a
 new one on Wednesday 1st March at 4pm UTC. Any opinions?
>>>
>>>
>>> Is it possible to change the time to 5pm?
>>
>>
>> I am fine with either time.
>>
>>>
>>>
 Also, do you have any specific topic you would like to talk during
 the next
 call?
>>>
>>>
>>> I would like to discuss progress on PV protocols and IRQ latency.
>>
>>
>> I will add them in the agenda.
>>
>> Cheers,
>>
>
> --
> Julien Grall
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] Xen ARM community call

[Anastassios Nanos]

Hi Julien, all,

> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.

great idea, I'd like to join too (GMT).

> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough

Another issue to discuss, at some point, could be big.LITTLE support
(based on 
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01802.html).

cheers,
A.

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