tech-kern archive

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

Re: pmf(9) and Xen domU suspending?

Joerg Sonnenberger wrote:
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 be
done reasonably, but domU doesn't care much (at all?) about the physical
Host system can be suspended to ram with Xen 3.2. But that is not my primary objective :)

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.
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.
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.



Home | Main Index | Thread Index | Old Index