diff options
author | Alex Williamson <alex.williamson@hp.com> | 2008-02-05 09:23:59 -0700 |
---|---|---|
committer | Alex Williamson <alex.williamson@hp.com> | 2008-02-05 09:23:59 -0700 |
commit | fe7521484fb7c586edac84d174bec956e6c874b7 (patch) | |
tree | 5af4ac9919d033110dc023740704d22918967348 /unmodified_drivers | |
parent | a37c72d0fc43b7ea1f993ac35b9ae8ab324bc4a0 (diff) | |
download | xen-fe7521484fb7c586edac84d174bec956e6c874b7.tar.gz xen-fe7521484fb7c586edac84d174bec956e6c874b7.tar.bz2 xen-fe7521484fb7c586edac84d174bec956e6c874b7.zip |
[IA64] Fix domain refernece counting
Fix the domain refernece counting caused by allocated pages from domheap for
shared page and hyperregister page. Calling share_xen_page_with_guest() with
domain heap page is wrong so that it increments domian->xenpages which is
never decremented. Thus the domian refcount doesn't decrease to 0 so that
destroy_domain() is never called. This patch make the allocation done from
xenheap again.
The other way to fix it is to work around domain->xenheap and the page
refrence count somehow, but it would be very ugly. The right way to do so
is to enhance the xen page allocator to be aware of this kind of page in
addition to xenheap and domheap. But we don't want to touch the common code.
And given that the limitation on xenheap of xen/ia64 is much relaxed,
probably it isn't necessary to be so nervouse not to allocate those pages
from xenheap. If it happend to be necessary to allocate those pages from
domheap, we could address it at that time. For now just allocate them from
xenheap.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Diffstat (limited to 'unmodified_drivers')
0 files changed, 0 insertions, 0 deletions