WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 05/10] xen/setup: Set identity mapping for non-RA

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 05/10] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 22 Dec 2010 10:04:21 -0500
Cc: Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx>, hpa@xxxxxxxxx
Delivery-date: Wed, 22 Dec 2010 07:06:10 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D112B80.9020600@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1292967460-15709-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1292967460-15709-6-git-send-email-konrad.wilk@xxxxxxxxxx> <4D112B80.9020600@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
> Couldn't you just do something like:
> 
>       if (e820->map[i].type != E820_RAM)

I am going to assume you meant '==' here.

>               continue;
> 
>       for (pfn = PFN_UP(last); pfn < PFN_DOWN(start); pfn++)
>               set_phys_to_machine(pfn, pfn);
>       identity += pfn - PFN_UP(last);
> 
>       last = end;
> 
> ie, handle the hole and non-RAM cases together?

A derivation of this does work:

   last = ISA_END_ADDRESS;
   for (i = 0; i < e820->nr_map; i++) {
                phys_addr_t start = e820->map[i].addr;
                phys_addr_t end = start + e820->map[i].size;

                if (end < start)
                        continue;

                /* Skip over the 1MB region. */
                if (last > end)
                        continue;

                if (e820->map[i].type == E820_RAM) {
                        /* Without saving 'last' we would end up gobbling RAM 
regions. */
                        last = end;
                        continue;
                }   

                for (pfn = PFN_UP(last); pfn < PFN_DOWN(end); pfn++)
                        set_phys_to_machine(pfn, pfn);
                identity += pfn - PFN_UP(last);

                last = end;
        }


> 
> Also, what happens with the p2m tree mid layers in this?  If you're
> doing page-by-page set_phys_to_machine, won't it end up allocating them
> all?  How can you optimise the "large chunks of address space are
> identity" case?

The issue here is that when this code path is called (xen_memory_setup),
the p2m_top[topidx][mididx] has been set to start_info->mfn_list[] (by
xen_build_dynamic_phys_to_machine).

Granted, some of these entries have been evicted (by the 
xen_return_unused_memory),
so the regions in the mfn_list are pock-marked with INVALID_P2M_ENTRY. For those
regions we set the PFN in the p2m_top[topidx][mididx][idx]. We do
not allocate anything during this pass.

In the the dom0_mem=max:X (or X,max:Y, where Y>X), which I neglected to test 
this
would actually try to allocate (whoops). Let me roll up a patch for this.

> 
> It would probably be cleanest to have a set_ident_phys_to_machine(start,
> end) function which can do all that.

Not sure if it is truly needed.

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

<Prev in Thread] Current Thread [Next in Thread>