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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Tue, Dec 06, 2016 at 11:02:20AM -0800, Stefano Stabellini wrote:
> 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)?

Hi All,

I'm up for a call the 14th. 4 or 5pm UTC both work for me.

Best regards,
Edgar


> 
> 
> 
> > 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@lists.xen.org
https://lists.xen.org/xen-devel