On Fri, Oct 17, 2008 at 05:36:58PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Fri, Oct 17, 2008 at 05:58:45PM +0900, Isaku Yamahata wrote:
> >> On Fri, Oct 17, 2008 at 04:45:09PM +0800, Xu, Anthony wrote:
> >>> Hi isaku,
> >>> If I remembered correctly, last time I encountered issue at line
> >>> page = mfn_to_page(mfn); Page returns 0.
> >> Which line do you have trouble?
> >> Do you mean that mfn_to_page(mfn) returned NULL?
> >> or
> >> Did you hit BUG_ON(page_get_owner(page) == NULL)?
> >>> I suspect if page_info for IOPORTs is initialized.
> >>> Any idea?
> > Ah, I think they are initialized, but they are free.
> > i.e. page refcount = 0, page owner = NULL.
> > So you may need to make them owned by DOMID_IO somewhere of the
> > initialization.
> > i.e. page refcount = 1, page owner = DOMID_IO
> I suspect it,
> Because xen doesn't know all MMIO information, xen just initiates page_info
> through efi memory description/
> Efi memory description doesn't provide MMIO information execpt PORT IO
It's correct that xen VMM doesn't fully understand io area.
However the VMM know all about RAM.
So far !mfn_valid() has sufficed for the current implementation
in order to detect IO area.
However you are going to into the case which needs more precise
detection. But what we want is the way to detect whether
the page is NOT conventional memory. Not io area.
There are three (or four) cases
- !mfn_valid() case
This means that there isn't a corresponding struct page_info.
So we just skip reference counting over this type.
- mfn_valid() case
- no ram
I suppose this is the case you want to address.
In this case, the corresponding struct page_info can
be owned by DOMID_IO.
This case needs to be addressed.
- conventional memory (EFI_MEMORY_CONVENTIONAL)
This case was already handled by the current implementation.
- other type RAM
I'm not sure whether this case matters.
If it matters, we can handle this case as same as no ram case.
Xen-ia64-devel mailing list