Re: [Xen-devel] reserve e820 ram

[Tim Deegan <tim@xxxxxxx>]

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.

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?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel