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] A different probklem with save/restore on C/S 14823.

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] A different probklem with save/restore on C/S 14823.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 13 Apr 2007 17:55:44 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 13 Apr 2007 09:53:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0B018E1BE9@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acd96tTWE6bfmOneEduH7gAWy6hiGQAACQawAABmlkU=
Thread-topic: [Xen-devel] A different probklem with save/restore on C/S 14823.
User-agent: Microsoft-Entourage/
On 13/4/07 17:47, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:

> See my other reply, although you may have a point about mapping - my
> guest is running with the HVMloaders map, which probably maps all memory
> available to guest linearly, including address zero (as that's where
> real-mode puts the interrupt vector table, which can be useful to have
> mapped - just a little bit ;-) ).
> So maybe we need an earlier/different test to kill guest? Or do you
> think this is such a critical error that hypervisor should die?

The NULL dereference is inside the hypervisor in hvm_do_resume(). At that
point you are running in Xen's address space, not the guest's. And Xen
should have no mapping at address zero.

The issue here is that shared_page_va is not initialised, so it contains 0.
hvm_do_resume() should be getting a pointer derived from this value via
get_vio(). When it dereferences it, Xen should crash. That didn't happen for
you and that is scarily inexplicable.

I suggest adding some tracing to hvm_do_resume() to find out whether it is
being called at all and, if it is, what value it sets its local variable 'p'
to. Also what value is in v->domain->arch.hvm-domain.shared_page_va.

The bugs that cause this condition should all be fixed in xen-unstable
staging tip, by the way. I just think this situation should be investigated
before you upgrade in case you've uncovered another latent bug. Because you
really should be crashing in hvm_do_resume() in this scenario.

 -- Keir

Xen-devel mailing list