Re: [Xen-devel] 15142:78389dbb08bb and domain state

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Fri, Nov 09, 2007 at 07:42:33AM +0000, Keir Fraser wrote:

> > It's the below changeset - no code to reset the domid exists any more.
> > It seems suboptimal to me? Shouldn't refreshShutdown (or somewhere,
> > anyway) remove domid?
> 
> Does this only happen for your special screwed domains that don't actually
> die?

I remember it being both, but it might have been - unfortunately I can
only create screwed domains at the moment (!).

> You can use the 'q' debug key to Xen to get it to print out per-domain info,
> including a list of held pages (if there's only one or two pages held) and
> their reference counts.

Thanks!

(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage 000000019ddbf000: mfn=000000000019ddbf, caf=00000001, 
taf=0000000080000001
(XEN) Memory pages belonging to domain 2:
(XEN)     DomPage 00000001f4dbc000: mfn=00000000001f4dbc, caf=00000001, 
taf=0000000080000001

#define PGT_l4_page_table   (4UL<<29) /* using this page as an L4 page table? */

Is it possible we do something unusual, and there's an accounting bug? It seems
that vcpu_destroy_pagetables() should kill any active reference. If I boot into
the kernel debugger (so no userspace) and destroy the domain, it still happens.

Before I try and work up something to track references to the kernel's
CR3 dompage, any suggestions or ideas?

thanks
john

PS what's the difference between PGT_base/root_page_table?

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