Joerg Sonnenberger wrote:
DomU.OK, That makes things a lot easier. If you have two more days, I can work out the details with Jean-Yves directly.
Great, thanks.Question regarding sysmon events though: in dev/sysmon/sysmon_power.c:965, the PSWITCH_TYPE_SLEEP case seems to catch the event for the SLEEP, but ends in a NOOP (when comparing it to other entries like RESET or POWERDOWN, which calls cpu_reboot(...) ). Does that mean that the SLEEP event should be handled somewhere else?
I do not know the exact behaviour regarding kernel state for a suspend-to-RAM. Xen manipulates MMU directly, the domu is not (well, there are some corner cases like writable page tables, but it adds up complexity when restoring a VM).On Sat, Mar 29, 2008 at 06:21:22PM +0100, Jean-Yves Migeon wrote:I am working on suspend/resume functionality for port-xen under the supervision of Manuel Bouyer (bouyer@) and Stoned Elipot (seb@). Currently, I am mostly trying to get familiar with NetBSD internals, and Xen.You mean the Xen eqivalent of suspend-to-RAM? Is this for domU or dom0?
I suppose that we will have some differences though, as a domu uses mostly "pseudo" physical frame numbers (Xen adds another level for memory mappings). And these mappings can eventually change upon a restore (between the pseudo physical addresses and the real machine ones).
For suspend-to-ram, I guess the OS keeps its PDs and PTs entries intact, since there is no reason for them to change between suspend and resume.
(As always, I may be wrong though). Thanks for the replies :) -- Jean-Yves Migeon jean-yves.migeon%espci.fr@localhost