RE: [Xen-ia64-devel] Community effort needed tocatch upwithxen-unstable

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: John Byrne [mailto:john.l.byrne@xxxxxx]
>
>I've gotten blkfront/blkback to work based on your patches and
>re-merging Matt's changes to them before the xen-unstable merge. I'm
>trying to get the netback/netfront drivers to come up, now. I'll have
to
>clean up some debugging before I can generate a patch. I will generate
a
>patch that is added in addition to your hg_cleanup_0831 patches.

Good to know that.
>
>BTW, I'm not sure I really believe how you fixed xc_linux_build(). (It
>seems to work, though.) I don't understand why you just didn't use the
>nr_pages passed into setup_guest for the number of pages to allocate.
It
>seems to me that you are implying a relationship to the number of pages
>compute from the image size and the number of pages assigned to the
>domain that may not hold.
>
>John Byrne

That's just a quick hack upon existing mechanism which mismatched as
common side. I'm not sure what's the exact relationship there. What I
did is just to allocate one extra pfn at the end of configured memory
trunks for specified domain. Normally on x86, all configured pages are
allocated before reaching xc_linux_build. However current ia64 approach
is to allocate machine pages only when ia64_get_pfn_list. So as you can
see there, to load domU kernel images, ia64_get_pfn_list is invoked only
with size of image. Following same syntax, I just query for last pfn by
same way which is the xenstore page. Though we can use nr_pages there,
it is only a partial fix and definitely we need to clean more also in
Xen.

Thanks,
Kevin

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