Hi all,
Stefano suggested to move the call at 5pm and I haven't seen any
disagreement.
So the call will be tomorrow (Wednesday 14th December at 5pm).
The conference details are the same as last time. For reminder:
Use either of the following to join the call:
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
Cheers,
On 06/12/16 13:48, 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?
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
