mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pekka Paalanen <pq@iki.fi>
To: avi@qumranet.com, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>
Cc: Christoph Hellwig <hch@infradead.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Pavel Roskin <proski@gnu.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	penberg@cs.helsinki.fi, vegard.nossum@gmail.com
Subject: Re: mmiotrace bug: recursive probe hit
Date: Fri, 4 Apr 2008 00:07:01 +0300	[thread overview]
Message-ID: <20080404000701.70bbc1a4@daedalus.pq.iki.fi> (raw)
In-Reply-To: <20080330202608.054702a4@daedalus.pq.iki.fi>

On Sun, 30 Mar 2008 20:26:08 +0300
Pekka Paalanen <pq@iki.fi> wrote:

> 
> C) Vegard mentioned something about per-cpu page tables for kmemcheck.
> This would be the ultimate solution, because it would solve two problems:
> - recursive probe hits
> - missed events due to another cpu disarming the page for single stepping
> Would it be possible to have a single temporary per-cpu pte?
> 
> I understood kmemcheck has similar issues. Of course, one could force the
> system down to a single running CPU, but that feels nasty.

One more idea:

D) Emulate the faulting instruction.
In __ioremap(), do the mapping, but steal it for mmiotrace's personal use,
and return a bogus mapping that is identifiable in #pf handler. When
something accesses the bogus mapping, emulate and step over the faulting
instruction using the stolen IO memory mapping. This would get rid of
the debug trap and single stepping, and also remove the need to disarm
the mmio page, which means tracing would work reliably on SMP without
any page table kludges. This would also remove the yet another instruction
decoding code that mmiotrace has.

The catch is the instruction emulation. I see KVM has some emulation code,
but I cannot understand it without a deep study that would take me weeks.
Is that general enough to be used, or could it be generalized?
Mmiotrace, apart from executing the instruction with a modified address,
would need to extract the type of IO memory access, width and the data
read/written. And since it is dealing with IO memory, the emulation
should be very careful to access the hardware exactly like the original
instruction would have.

Maybe also kmemcheck could use this approach, since the current approach
is very much like in mmiotrace: #pf, show page, single step, #db trap,
hide page.

Are there other x86(_64) instruction emulation facilities in the kernel
I might use?

Or, if the emulation cannot be used, what would it take to make at least
instruction decoding general enough so that mmiotrace could use that instead
of its own decoding?

I fear modifying KVM emulation code is a too heavy job for me personally.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

  reply	other threads:[~2008-04-03 21:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-09 14:40 [RFC] mmiotrace full patch, preview 2 Pekka Paalanen
2008-03-09 14:46 ` Pekka Paalanen
2008-03-27 23:13 ` Vegard Nossum
2008-03-28 18:24   ` Pekka Paalanen
2008-03-28 20:25 ` mmiotrace bug: recursive probe hit Pekka Paalanen
2008-03-30 17:26   ` Pekka Paalanen
2008-04-03 21:07     ` Pekka Paalanen [this message]
2008-04-03 21:40       ` Vegard Nossum
2008-04-04 13:18         ` Pekka Paalanen
2008-04-05  7:36       ` Avi Kivity
2008-04-05  7:40         ` Pekka Enberg
2008-04-05 12:39           ` Avi Kivity
2008-04-05 15:58             ` Avi Kivity
2008-04-06 17:32         ` Pekka Paalanen

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=20080404000701.70bbc1a4@daedalus.pq.iki.fi \
    --to=pq@iki.fi \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=avi@qumranet.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=proski@gnu.org \
    --cc=rostedt@goodmis.org \
    --cc=vegard.nossum@gmail.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

all inboxes | Powered by JetHome®