Re: Xen ARM community call - meeting minutes and date for the next one

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3949 bytes --]

On Tue, 2016-12-06 at 13:48 +0000, Julien Grall wrote:
> === big.LITTLE ===
> 
> Anastassios:    interested in knowing the status of big.LITTLE
> support in Xen
> Dario:          went through the thread on the ML. The consensus
> seems to be
>                 based on vcpu pin/affinity.
> Anastassios:    There are issue the way xen handles boot code. Wrong
> errata
>                 for cpus.
> Julien:         Core could have different errata and features. Errata
> already
>                 works today.
>                 We need a summary of the discussion.
> 
> Dario stepped in to write a summary.
> 
> Anastassios:    What is the best board to work big.LITTLE with Xen?
> 
> ?:              Renesas
> 
> ACTION: Dario to write a summary of the big.LITTLE discussions.
> 
Here it is. I took the chance and wrote it as a design / feature
document, but it still has some TODO, for things that were either not
clear or not fully agreed upon in the thread.

 [DOC RFC] Heterogeneous Multi Processing Support in Xen
 <1481135379.3445.142.camel@citrix.com>

(I wanted to post a link to the message in the archives, but I'm not
seeing it there yet... oh, well.)

Hope this helps. :-)

Regards,
Dario

> === Secure Call Monitor (SMC) from guests ===
> 
> Andrii/Artem:   EPAM is working on allowing a guest to make call to
> TEE (e.g
>                 OPTEE). They are working in collaboration with Linaro
> to
>                 make OPTEE  virtualization aware. A design document
> has been
>                 posted on the ML (see [3]).
> Edgar:          interested on this. Trusted world need to be accessed
> to
>                 manage FPGA and for power management
> 
> === Running unmodified baremetal software in a guest ===
> 
> Edgar:          Xilinx is working on running unmodified baremetal
> software
>                 in a guest. Piece of work required:
>                     - Mapping memory area with different memory
> attribut
>                       to domU
>                     - Replicate host memory map
>                     - Exposing a vUART to guest (see [4] for the
> discussion)
> Steward:        vUART is very important, especially for baremetal
> guests
> Stefano:        it would need to be loggable
> Julien:         we would have the same issue in the future to be
> compliant
>                 with the VM Spec (see [5]).
> 
> === Areas of concern ===
> 
> Bosch: problem with xen-swiotlb. It does not work properly on renesas
> board.
> Stefano: please report the error on the ML
> 
> ACTION: Bosch to send a bug report regarding xen-swiotlb
> 
> Edgar:  IOMMU could not be used by the guest (Stage-1). This would be
> useful
>         to implement driver in userspace.
> Julien: When will it be required?
> Edgar:  It is a trend
> 
> Julien: Should we organized another Community Call? When?
> Artem: Once per month is a good start
> 
> All: Agreed on a call before Christmas
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg0
> 1966.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg0
> 1802.html
> [3] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg0
> 2220.html
> [4] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg0
> 0846.html
> [5] http://people.linaro.org/~christoffer.dall/VMSystemSpecificationF
> orARM-v2.0.pdf
> 
-- 
<<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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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