| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
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
|
|
|
| |
|
Home