[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Minutes of the Xen ARM community call Tuesday 13th February 5PM UTC

Hi all,

These are the minutes of the meeting we had earlier this week. Thank you
all for attending!



Attendees: Stefano Stabellini, Julien Grall (ARM), Artem Mygaiev (EPAM),
Mirela Simonovic (Aggios), Davorin Mista (Aggios), Christopher Clark,
Andrii Anisov (EPAM), Rich Persaud, Nicole Chalhoub, Anthony Toubeau,
Volodymyr Babchuk (EPAM), Oleksander (EPAM), Kristophor (DornerWorks).

= GPU virtualization =

Artem: Coprocessor framework is used for virtualization, on top of it
there is a component based on Imagination Technology guidelines. PV
drivers are too slow. EPAM used a different way. The implementation with
Imagination Technology doesn't completely switch GPU context. Instead,
we signal the GPU to switch domain. The firmware is doing most of the
work. There are limits by the GPU for number of contexts (number of VMs
that can have a vGPU). Also RAM could be a limitation. Most GPUs have
their own MMU, and securing those is difficult. Only 300LOC for the
Imagination Technology specific driver. Almost nothing Imagination
specific in the hypervisor -- the solution relies heavily on the generic
coprocessor framework.  EPAM will submit it to xeb-devel again soon.

Question by Artem: is there interest to virtualize Mali?
ACTION Julien: I'll make introductions

= Suspend/Resume Demo =

Mirela: Xen suspend/resume on Xilinx MPSoC
1.8W = 1.5 (aarch64 cores) + 0.3 (low power domain)

Create 1 more Linux DomU: power consumption goes to 2W temporarily, then
back to normal because it is idle.
Suspend the domU linux -> no change, it was already idle.
Load a bare metal guest: power consumpion increases because it is idle
looping. Small differece, about 0.1W. Suspend it and goes back to
Dom0 suspends, then Xen suspends.
Any interrupt can wake up the whole system.
0.035W consumption after suspend.
PSCI based suspend.

ACTION Stefano Send link to suspend/resume design doc to Artem.
See below. [1]

= AGL Whitepaper =
Artem: please review the whitepaper, most of the content is already
Everybody agrees that Xen Project should publish its own whitepaper.

Certifications are mostly not about the code. Artem about to share an
analysis done by third parties on certification gaps. Then, we'll
organize another call.
ACTION Artem: send out the gap analysis

[1] https://marc.info/?l=xen-devel&m=151396462523580

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.