[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |