Re: [Xen-ia64-devel] [PATCH] make xenLinux/ia64 privcmd mmap not to use dom0 memory.

[Alex Williamson <alex.williamson@xxxxxx>]

On Thu, 2006-05-18 at 22:37 +0900, Isaku Yamahata wrote:
> Alex.
> xen_ia64_privcmd_init() tries to guess where pseudo physicall address
> region can be used for the priv cmd mmap by heuristics.
> Although I tested this patch on tiger2 and tiger4, I'm not sure
> about other platforms.
> Because your testing box has more complicated memory arrangement,
> Could you confirm it?

Hi Isaku,

   Yes, this seems to work on box:

xen privcmd uses pseudo physical addr range [0x10100000000, 0x3ffff000000]

> +
> +static int __init
> +xen_ia64_privcmd_init(void)
> +{
> +        void *efi_map_start, *efi_map_end, *p;
> +        u64 efi_desc_size;
> +        efi_memory_desc_t *md;
> +       unsigned long tmp_min;
> +       unsigned long tmp_max;
> +       unsigned long gap_size;

   Should we have a xen_init()/running_on_xen() and dom0 check here?  I
don't think we want to initialize this on either the transparent
virtualization or the domU case, right?

> +       
> +        for (p = efi_map_start; p < efi_map_end; p += efi_desc_size)
> {
> +               md = p;
> +               if (md->attribute & EFI_MEMORY_WB) {
> +                       tmp_min = md_end_addr(md);
> +               }
> +       }
> +       privcmd_resource_min = GRANULEROUNDUP(tmp_min);

   Can this range overlap non-WB ranges?  If so, it seems strange that
we would go to so much trouble trying to tuck this at the end of memory
or in a hole.  Thanks,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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