Re: [Xen-devel] [hybrid] : mmap pfn space...

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 04/13/2012 09:47 PM, Mukesh Rathor wrote:
> On Mon, 26 Mar 2012 11:37:46 +0100
> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> I think that we should explicitly allocate these pages/addresses and
>> not rely on the fact that they are at a specific location that we deem
>> safe for now.
>> So if we explicitly introduce a new region at the end of the e820 that
>> we mark as reserved and we use it for this, I would be OK with that.
>> However we need to be careful because editing the e820 has proved to
>> be challenging in the past.
>> Also we would need to figure out a way to tell Linux that these
>> reserved addresses are actually OK to be used. Maybe we need a new
>> command line or hypercall for that.
> 
> That sounds like reasonable approach. Lets do it as part of phase II.
> I wanna get some basic code in.
> 
> So, to give an update of where I am, good news, I've got guests 
> finally booting using hybrid dom0. So, that means I am almost there 
> now!!!! Yeay...
> 
> But, the pfn space management for privcmd mapping is still a hack. 
> Running into many issues. Basially, it is forcing me to write a slab
> allocator for the resvd pfn space, that I am trying to avoid. During
> guest creation, xl process maps about 10k foreign pgs, and xenstored 1.
> 
> I was thinking of just dividing my pfn space into say 10 chunks, each
> with 10k pages, so 10 guest creations can happen simultaneously. But,
> then xl is not the only process doing the mapping I found out. xenstored
> also needs to map domU frames.

With Xen 4.2, xenstored should be using the grant table for its shared
page. Similar changes can be made to xenconsoled so that only the domain
build/migrate processes use map_foreign_range. I have a patch to xenconsoled
without the fallback to map_foreign_range sitting around; I was planning to
post it with proper fallback (which I may do soon, looks simple enough).

> Otherwise, I could just do one chunk
> per process. Also, I am breaking mmap semantics somewhat by hooking
> via privcmd_mmap, because the unmaps don't follow any order. So my last
> unmap frees the entire 10k chunk it's using. 
> 
> In a nutshell, I am still trying to figure how to allocate rsvd pfn's 
> for privcmd without writing a slab allocator. I think using mmap makes
> it harder, can't we just use ioctl to get the VA? Then, I could nicely
> do something like:
>   xl: 
>     - open(privcmd file)
>     - ioctl(get rsvd/e820 pfn handle)
>     - ioctl(get VA using above handle) /* alternate to mmap */
>     - ioctl(get VA1 using above handle) /* alternate to mmap */
>     ...
>     - ioctl(release handle)
>     - ioctl(release VA)
>     - close file
> 
> Is that an option (to change mmap to ioctl)? 
> 
> Hope that makes sense,
> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


-- 
Daniel De Graaf
National Security Agency

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