Re: [Xen-devel] A different probklem with save/restore on C/S 14823.

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel