This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Detecting deadlocks with hypervisor..

Keir Fraser wrote:

On 7 Apr 2006, at 18:11, T S wrote:

We took a look at the xc_linux_save() function ... and what we see is that the canonicalize action is actually done by the Dom-0 (and not by the Dom-U); Dom-0 is able to do this because it is able to access the page tables of Dom-U as well as the pfn2mfn list of the Dom-U. Based on this, we think the Dom-0 can actually save the 'context' of the deadlocked Dom-U. Please correct me if this
claim is wrong.

Also, given that Dom-0 can access the page tables and other structures of the deadlocked guest, can one of you be able to tell me what changes I need to do to xm_linux_save( ) (and other related functions) to save the state of the deadlocked guest without doing any handshake with the guest OS ?

You can get at the consistent state of a guest by pausing it and then reading its state. However, the reason for the handshake is to ensure that the guest is not currently accessing pagetables or doing other critical operations. If it were then we could not safely translate its memory page addresses as it could have those addresses in places like its kernel stacks or register contexts, where they would not get translated and would cause a crash on restore.

I should add that this is a problem specific to writable page tables as the guest must be aware of the actual physical pages that it is using. With a VT/SVM guest or on an architecture that doesn't use writable page tables, this isn't an issue.


Anthony Liguoi

 -- Keir

Xen-devel mailing list