Joerg Sonnenberger wrote:
Host system can be suspended to ram with Xen 3.2. But that is not my primary objective :)On Thu, Apr 03, 2008 at 05:03:59PM +0200, Jean-Yves Migeon wrote:That's why I was asking about dom0 vs domU. I am not sure if dom0 can bedone reasonably, but domU doesn't care much (at all?) about the physical allocation.
domu does not care much about physical allocation, except if the domu kernel uses machine frame numbers directly (which can be the case in some part of the kernel for i386, with no software TLB, and no HVM support). Note that it is highly architecture specific, and contained in a shared info page given by hypervisor when starting a domu.
The only thing I can think of now is re-establishing the communication between the virtual Xen device (and bus) and the backend driver in dom0, and that is effectively done with a call to hypervisor for a va_mapping in order to share a page between domains. Other than that, I am not really sure: any part of the kernel relying on variables obtained before suspend through functions like xpmap_ptom() (pseudo physical to machine) has a potential impact upon restore, since machine addresses are no longer valid. But I am concentrating on pmf(9) and virtual device suspend first.I would advise you to look at acpi_enter_sleep_state first. Basically, for now trigger the suspend via a sysctl. The pmf_system_* calls are for suspending devices. The virtual Xen devices should detach themselve from the hypervisor on suspend and look for the corresponding new resource on resume. For the low level code you might not need to do anything at all, but call some function of the hypervisor. I am not sure.
Cheers jy