* Gerd Hoffmann (kraxel@xxxxxxx) wrote:
> Keir Fraser wrote:
> > Oh, I see it's moved to a new function. I guess that's okay, although
> > couldn't you fake up an e820 map and call legacy_init_iomem_resource on
> > the domU path, rather than having to pull code out into a new function?
> > Does this patch change behaviour for dom0 at all? I think /proc/iomem
> > already looks like native there? Also the patch will need to include
> > x86/64 too.
>
> new version attached.
Might want to double check against linux-2.6.tip-xen, as that code has
changed a bit since 2.6.16.
> diff -r c191c649cdb3 linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c
> --- a/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c Tue Jun 6
> 09:25:59 2006
> +++ b/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c Wed Jun 7
> 19:24:19 2006
> @@ -1378,7 +1378,6 @@
> res->end = res->start + e820[i].size - 1;
> res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> request_resource(&iomem_resource, res);
> -#ifndef CONFIG_XEN
> if (e820[i].type == E820_RAM) {
> /*
> * We don't know which RAM region contains kernel data,
> @@ -1391,7 +1390,6 @@
> request_resource(res, &crashk_res);
> #endif
> }
> -#endif
> }
> }
>
> @@ -1460,8 +1458,16 @@
> int i;
>
> /* Nothing to do if not running in dom0. */
> - if (!(xen_start_info->flags & SIF_INITDOMAIN))
> + if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> + struct e820entry domU_e820 = {
> + .addr = 0,
> + .size = max_pfn << PAGE_SHIFT,
> + .type = E820_RAM,
> + };
Or just do this during normal setup, then it is the base e820 map. I
believe it's already done isn't it?
memmap.nr_entries = 1;
map[0].addr = 0ULL;
map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
/* 8MB slack (to balance backend allocations). */
map[0].size += 8 << 20;
map[0].type = E820_RAM;
...
BUG_ON(copy_e820_map(map, (char)memmap.nr_entries) < 0);
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home