[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] reserve e820 ram

From: Tim Deegan [tim@xxxxxxx]
Sent: 05 April 2012 11:37
To: Francisco Rocha
Cc: xen-devel@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] reserve e820 ram

At 12:52 +0100 on 29 Mar (1333025578), Francisco Rocha wrote:
> Why is e820 being used in arch_init_memory (xen/arch/x86/mm.c in my
> case) and not boot_e820 (the one we changed)?  I am asking because
> from what I understand this will make my use of reserve_e820_ram
> useless, but I think I still not have all the information I need to
> know how it all connects.

arch_init_memory() is only using e820 to find out which addresses are
MMIO regions.  If we were to use boot_e820 we would mark all the
reserve_e820_ram()'d regions as MMIO, which is probably not what you

> To create a range that I can later use as a guest's RAM can I use
> dom_cow instead of dom_io in arch_init_memory?

No! dom_cow is the owner of all copy-on-write shared pages.  You don't
want to get your reserved area caught up in that lot. :)

> Or will that create problems when allocating the pages to an
> unprivileged domain?  I don't want that memory range in use by the
> main memory pool used by the allocators.

AIUI just calling reserve_e820_ram() to exclude the memory from
boot_e820 should DTRT.  Is that not working for you?

> From what I understand. The pages must have to be assigned to a particular 
> domain, dom_xen|io|cow.
> I see this as keeping them mapped and usable before assigning them to the 
> domU I want. Is that thought correct?

I think it shoudl be OK to leave them with no owner -- as long as
they're not in the memory allocator's free pools they won't get given to
any other domain.  Then once you're ready to use them you can assign the
directly to your domU.

How would this "assign" be done? Because when I remove them from the boot_e820 
they are not mapped. That confuses me a bit.

Another option would be to assign them to dom_xen and use
share_xen_page_with_guest to let domU map them.

Can you give us some details about how your current approach is failing?

So far I have tried this approach.

1. use reserve_e820_ram() with boot_e820 to avoid the main memory pool.

2. use reserve_e820_ram() with e820 and change arch_init_memory() to 
assign the reserved range to a dummy domain I have created and let it 
process the IO areas as normal.

One of the problems happens here because some of the mfns are invalid and I 
always end up getting 65536 pages assign to my domain when I count them using
page_list_for_each. Why is this happening? I am not able to understand it yet.
I have been exploring the pdx_groups to see if it is related.

3. I was planning to change populate_physmap to get the memory from the dummy 
domain. I would have to condition the calls to alloc_domheap_pages and use 
share_xen_page_with_guest, is that it? This part is still not very clear to me.
I was hoping to do something like going through the dummy domain's page list 
and steal them from it. :-)



Thank you for the help, cheers,
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.