On Mon, Jun 20, 2011 at 07:51:58PM +0200, Olaf Hering wrote:
> On Mon, Jun 20, Tim Deegan wrote:
>
> > Hi,
> >
> > At 17:26 +0200 on 20 Jun (1308590816), Olaf Hering wrote:
> > > The code to walk the pagetables is/was based on
> > > xc_translate_foreign_address(), but I still think I have some major bugs
> > > in
> > > there (the last patch). I cant figure out why some l3/l2/l1 entries can
> > > not be mapped.
> > > Any help with getting that output fixed for at least a a 64bit PV guest
> > > is much
> > > appreciated.
> >
> > I didn't spot anything broken in the walker (though it will need a bunch
> > of cleaning up) and the output looks very plausible. I take it this is
> > a PV guest? Is it a well-behaved one or a broken post-migrate one?
>
> Yes, its a PV guest. I cant reproduce the migrate crashes, it happens
> only on very few systems or on a certain configuration. The logs I
> posted are from my test system.
> Any ideas why some mfns are not accessible?
They look to be the special I/O PFNs. The ones that cover ACPI, framebuffer,
PCI IO bars, MP tale.
>
> Are there any other paging states maintained outside of the guests
> memory?
They look to be I/O pages.
But not sure why they are mapped to your guest?
>
> > One thing that might be causing trouble is if the domain's not paused
> > while you do the walk, then you might see inconsistent tables, though
> > I'd expect them to be garbage rather than looking like this. Your patch
> > 3/5 does seem to make the pausing conditional where before it always
> > happened.
>
> It tries it preserve the state, if the guest was paused it probably
> should not be unpaused. Is the dominfo.paused flag somehow unreliable, I
> thought it comes right from struct domain?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home