[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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

#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?


PS what's the difference between PGT_base/root_page_table?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.