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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 6 Dec 2016, Julien Grall wrote:
> Hi all,
> 
> Apologies for the late sending. You will find at the end of the mail a summary
> of the discussion. Feel free to reply if I missed some parts.
> 
> At the end of the call we agreed to have another meeting before the end of the
> year. Given that the Christmas is approaching and some people may take 
> holidays
> around, I would suggest to do the meeting on Wednesday 14th December at 4pm
> UTC. Any opinions?

Would it be possible to move this call to 5pm UTC (this one, not
necessarily all the future calls)?



> Also, do you have any specific topic you would like to talk during the next 
> call?
> 
> Cheers,
> 
> == Attendees ==
> 
> Apologies if I misspelled any name.
> 
> * Stefano Stabellini:
>     Aporeto, Xen ARM maintainer
> * Julien Grall
>     ARM, Xen ARM maintainer
> * Artem Mygaiev, Andrii Anisov, Alexandre Agizim:
>     EPAM, Embedded and automotive application for Xen
> * Steward Hildebrand:
>     Dornerworks, help customer to use Xen in their product
> * Edgar Iglesias:
>     Xilinx, Embedded and datacenter application
> * Meng Xu:
>     University of Pennsylvania, RT Xen. Looking for improving performance for
>     real-time application in virtualised environment
> * Bosch (sorry I forgot the name of the attendees): Car multimedia
> * Anastassios Nanos:
>     OnApp, using Xen on lower power server
> * Dario Faggioli:
>     Citrix, scheduler maintainer. Interested in following big.LITTLE 
> discussion
> 
> == Features ==
> 
> === Co-processor architecture ===
> 
> Artem:  EPAM is working on a co-processor framework to share resources between
>         guests (see a RFC of the design document [1]). A prototype has been
>         created by sharing a GPU between guests, the overhead is ~5% compare
>         to native.
> Julien: concerned about context switch time
> Stefano: concerned about the size of the emulator and security impact
> Edgar:  it might not be possible to know the FPGA accelerator when building
>         Xen.
> Stefano: having the emulator in Xen EL1 would be better for protection
> Andrii: it is not necessary to implement a full co-processor emulator. It is
>         sufficient to emulation the behavior on register write.
> 
> ACTION: Continue the discussion on the mailing list.
> 
> === 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.
> 
> === 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/msg01966.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01802.html
> [3] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
> [4] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00846.html
> [5] 
> http://people.linaro.org/~christoffer.dall/VMSystemSpecificationForARM-v2.0.pdf
> 
> -- 
> Julien Grall
> 

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