[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080110010111.GF18480@one.firstfloor.org>
Date: Thu, 10 Jan 2008 02:01:11 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Andi Kleen <andi@...stfloor.org>,
Christoph Hellwig <hch@...radead.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Pavel Roskin <proski@....org>, Dave Airlie <airlied@...il.com>,
Pekka Paalanen <pq@....fi>, linux-kernel@...r.kernel.org,
jbeulich@...ell.com
Subject: Re: Replacement for page fault notifiers?
On Wed, Jan 09, 2008 at 04:55:15PM -0800, Arjan van de Ven wrote:
> On Thu, 10 Jan 2008 01:47:16 +0100
> Andi Kleen <andi@...stfloor.org> wrote:
>
> > Arjan van de Ven <arjan@...radead.org> writes:
> > >
> > > I'm btw all in favor of making mmio tracing full fledged kernel
> > > infrastructure. This doesn't mean "notifier" imo; this means a real
> > > flag in the struct page, and then the page fault code can do
> > >
> > > if (page->flags & FLAG_MMIO_TRACED)
> > > mmio_trace(page, regs, whatever..);
> > >
> > > (probably surrounded by a CONFIG_ ifdef)
> > > THis is a TON lighter than a notifier chain, and actually what you
> > > want, you don't really want a notifier, you want a call back when a
> > > special kind of page is touched.
> >
> > That would assume that your mmio area has a struct page. In most PCs
> > the ones in the PCI hole don't
> >
>
> so you also call the function for all traps on pages without struct page;
> that should be extremely rare anyway, and the mmio_trace code can then
> look the page up.
But there's really no page to look up. These are typically !pfn_valid()
You would need to create an own backing infrastructure. Perhaps you can reuse
some of that from the future PAT code, but integrating that into the page fault
will be probably ugly.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists