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

RE: [Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/5] dump-core take 2:



>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2007年1月18日 17:25
>
>On Thu, Jan 18, 2007 at 04:54:05PM +0800, Tian, Kevin wrote:
>> Yeah, memory map may be sparse on ia64, but, only at physical level.
>> You can always present a compact pseudo physical layout to a
>> domain, despite of sparse or not in real physical.:-)
>
>That's right. Xen/ia64 does so now for paravirtualized domain
>except dom0.
>There is an unsolved issue. If much memory (e.g. >4GB) is given
>to a driver domain, the domain can't access I/O.
>At least the I/O area must be avoided somehow,
>thus paravirtualized domain's memory map may become sparse
>(in the future when the issue is solved).

Yes, if I/O regions are very sparse, so does memory map for driver 
domain.

>
>
>> BTW, is it possible
>> to save memmap into xenstore, so that multiple user components can
>> communicate such info directly without xen's intervention?
>
>Do you have any usage in mind?

Case like your above requirement, case like qemu, and even case 
like save/restore... anyway, to me there's no need to let Xen aware 
of the domain memmap. Domain image builder constructs the memmap 
based on its configuration, and then just notify xen to allocate pages for 
appropriate regions or setup mapping for assigned MMIO ranges. If 
builder also saves memmap to xenstore, you don't need above 
hypercall then. Just an alternative...

Thanks,
Kevin

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


 


Rackspace

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