From: Konrad Rzeszutek Wilk <konrad.wilk@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] : mapping IO mems in the EPT
Date: Mon, 18 Jun 2012 14:35:57 -0400 [thread overview]
Message-ID: <20120618183557.GA28050@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote:
> On Fri, 15 Jun 2012, Mukesh Rathor wrote:
> > Hi guys,
> >
> > During my refresh to latest linux, I noticed, direct mapping of all
> > non-RAM pages in xen_set_identity_and_release(). I currently don't map
> > all at front, but as needed looking at the PAGE_IO bit in the pte. One
PV doesn't look at that all the time either. The P2M tree code
has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will
automatically stick _PAGE_IOMAP on the PTE.
> > result of that is minor change to common code macro:
> >
> > __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
> > to __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)
I am really wafling on that. Jeremy posted a patch some time ago
to x86 folks that would do something similar (I can't remember the
details), but hpa said - why don't you just consult the E820.
That is where the IDENTITY_FRAME_BIT thing in the P2M tree came
about. It could probably be implemented for your cases using ranges.
Similary to how Xen permits/disallows certain IO regions to be touched.
Would something like that potentially allow you do something like this:
xen_hybrid_pte()
phys_addr_t phys = pte.pte & PTE_PFN_MASK
if (phys .. within ranges)
pte |= _PAGE_IOMAP;
return pte;
> >
> >
> > To avoid this change, and keep all my changes limited to xen files only,
> > I thought I could just map the entire non-ram pages up front too. But
> > I am concerned the EPT may grow too large? Specially, when we get to
> > *really* large NUMA boxes. What do you guys think? Should I worry about
> > it?
Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them
having gobs of RAM regions, but non-RAM regions?
>
> I would map them all up front and worry about it later.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-06-18 18:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 1:43 [HYBRID] : mapping IO mems in the EPT Mukesh Rathor
2012-06-15 11:02 ` Stefano Stabellini
2012-06-18 18:35 ` Konrad Rzeszutek Wilk [this message]
2012-06-19 9:21 ` Jan Beulich
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=20120618183557.GA28050@phenom.dumpdata.com \
--to=konrad.wilk@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.