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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: 16 April 2007 18:43
> To: Petersson, Mats; Tim Deegan
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] A different probklem with 
> save/restore on C/S 14823.
> 
> On 16/4/07 18:20, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:
> 
> >>> I will look at it on Monday (before I update to the new
> >> version, just to
> >>> make sure I can reproduce it still ;-) ).
> >> 
> > Ok, so some further checks, and it looks like address zero 
> (0-0xfff) is
> > mapped in, read/write. I haven't looked at the page-table, 
> just tried to
> > write to the pointer that is zero and it didn't "crash".
> > 
> > Any thoughts on where I should head off on this for tomorrow.
> 
> What sub-arch is Xen built for (32, pae, 64)? Are you using 
> NPT or shadow
> mode? 

64-bit, shadow mode. [Haven't even got a machine with NPT :-(]

> I'd suggest write a bit of code to dump %cr3, and check 
> e.g., are you
> running on the v->arch.monitor_table. Dump all entries in the 
> top-level page
> directory -- are they all populated, or is entry 0 the only 
> lowmem one to be
> populated? Dump the pagetable walk all the way down to the mapping of
> address 0: what machine address is mapped there?

Whilst I agree this is a good path to go down, I'm not quite sure why
cr3 would point anywhere but to monitor_table, is there any (legal) case
where cr3 isn't this value when in the hypervisor?

--
Mats

> 
> I.e., basically just dump some interesting stuff and let's 
> narrow it down
> from there.
> 
>  -- Keir
> 
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel