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

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

On Tue, Mar 28, 2017 at 04:23:03PM +0100, Julien Grall wrote:
> Hi all,
> 
> Apologies for the late sending, you will find at the end of the e-mail a
> summary of the discussion from the previous call. Feel free to reply if I
> missed some parts.
> 
> I suggest to have the next call on the 5th April at 5PM UTC. Any opinions?


That works for me, thanks!

Edgar


> 
> Also do you have any specific topic you would like to talk during this call?
> 
> Cheers,
> 
> == Attendees ==
> 
> Apologies if I misspelled any name.
> 
> Stefano, Aporeto
> Julien, ARM
> Oleksandr, EPAM
> Artem, EPAM
> Thanasis, OnApp
> Volodymir, EPAM
> 
> == Xen on ARM status ==
> 
> Over 100 patches in-flight for Xen on ARM:
>     - PV protocols: Some are already accepted
>     - NUMA support
>     - GICv3 ITS support
>     - Exposing and emulating a PL011 for guest
>     - guest SMC forwarding for Xilinx platform
>     - Interrupt latency improvement
> 
> == PV protocols ==
> 
> * PV protocols written by Stefano was merged after 10 months
> 
> Stefano: PV protocols review are moving faster
> Attendees agreed
> 
> * Audio protocol: close to be accepted
> * Display protocol: minor issue, a bit more design is required
> 
> Hopefully both will be ready for Xen 4.9
> 
> Oleksandr: What to do when the backend die?
> 
> (I cannot find any notes on it some I am not sure if we answered the question
> during the call. I suspect it has been asked to bring up the subject on the 
> ML).
> 
> == Interrupt latency ==
> 
> Stefano: Some improvement has been done but it is not possible to know whether
> it is good. Do you have any specific IRQ latency requirements?
> 
> Artem: There is no hard latency requirements in automotive, although many
> requirements depends on latency. For example:
>     * Scheduling
>     * GPU (implementation is sentive to interrupt latency)
> 
> Automotive is using a set of benchmark to find the virtualization overhead. 
> This
> should be low.
> 
> ACTION: Artem to send a list of benchmark
> 
> == SMC/HVC handling in Xen ==
> 
> Artem: Please review the proposal on the mailing list. See:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg00430.html
> 
> == Deprivilege mode ==
> 
> EPAM are working on adding support for OP-TEE in Xen to allow multiple guest
> access the trusted firmware.
> 
> During the discussion on the design, it was suggested to move the SMC handling
> in a separate domain. This was tested using the VM event API and Mini-OS
> (upstream with Chen Baozi's series to support ARM64). The first results
> shows it is 10 times slower than handling SMC calls directly in the 
> hypervisor.
> 
> Volodymir is working on another approach to deprivilege the execution by
> implementing a Xen EL0.
> 
> == big.LITTLE support ==
> 
> Thanasis: Document discussed on the ML. Xen will split CPUs at boot time
> (big vs little). A series will be sent on the on the ML soon.
> 
> -- 
> Julien Grall

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