[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, 28 Mar 2017, 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? Works for me. > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |