From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [hybrid] : mmap pfn space...
Date: Fri, 13 Apr 2012 18:47:05 -0700 [thread overview]
Message-ID: <20120413184705.77b4d316@mantra.us.oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203261125470.15151@kaball-desktop>
On Mon, 26 Mar 2012 11:37:46 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> 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. 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
next prev parent reply other threads:[~2012-04-14 1:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 18:01 [hybrid] : mmap pfn space Mukesh Rathor
2012-03-26 10:37 ` Stefano Stabellini
2012-03-26 10:40 ` Ian Campbell
2012-04-14 1:47 ` Mukesh Rathor [this message]
2012-04-16 14:14 ` Ian Campbell
2012-04-16 16:22 ` Stefano Stabellini
2012-04-16 16:26 ` Ian Campbell
2012-04-18 1:20 ` Mukesh Rathor
2012-04-18 8:33 ` Ian Campbell
2012-04-16 14:39 ` Daniel De Graaf
2012-04-16 14:59 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120413184705.77b4d316@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Xen-devel@lists.xensource.com \
--cc=stefano.stabellini@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).