[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] A different probklem with save/restore on C/S 14823.
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.
Xen-devel mailing list