Hi Oleksandr, Edgar,
Thanks, you're right.
On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:
On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
Hi Mirela,
Just some remarks regarding the scope of work:
+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+ * Disable wathdog on suspend, enable it on resume
+ * Pause domains on suspend, unpause them on resume
+ * Disable non-boot pCPUs on suspend, enable them on resume
+ * Save/restore of GIC configuration
+ * Suspend/resume timer
+ * Save/restore of EL2 context
+ * Implement resume entry point in Xen, including MMU configuration
I think that saving/restoring IOMMU registers/context should be
implemented as well.
Yes, good point.
Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
with the FPD.
Yes, it is in FPD.
In other words, each involved platform device driver in Xen on ARM
(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
implemented.
Yes, callback should be platform specific but not each platform has to
have all callbacks implemented. E.g. on ZU+ UART is in differrent power
domain compared to APU/Xen. Xen can suspend and its power domain can go
down even if UART is not suspended. However, suspending UART even in
this case may be beneficial from power perspective. We should definitely
provide the option to implement the callback.
AFAIU, the following devices has to be suspended:
1. timer
2. IOMMU
3. UART
4. GIC
Please let me know if I missed something. I'll update this in next
design spec version. Thank you very much for good feedback!
Cheers,
Mirela
Yes agreed.
Best regards,
Edgar
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
