[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 want. > 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. :-) Cheers, Tim. Thank you for the help, cheers, Francisco _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |