From: Hollis Blanchard <hollisb@us.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Gregory Haskins <ghaskins@novell.com>,
Avi Kivity <avi@redhat.com>, Chris Wright <chrisw@sous-sol.org>,
Gregory Haskins <gregory.haskins@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: PowerPC page faults
Date: Tue, 12 May 2009 09:50:56 -0500 [thread overview]
Message-ID: <200905120950.57118.hollisb@us.ibm.com> (raw)
In-Reply-To: <4A08A411.9060104@codemonkey.ws>
On Monday 11 May 2009 17:17:53 Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Mon, 2009-05-11 at 12:54 -0500, Anthony Liguori wrote:
> >
> >> For future ppcemb's, do you know if there is an equivalent of a PF exit
> >> type? Does the hardware squirrel away the faulting address somewhere
> >> and set PC to the start of the instruction? If so, no guest memory load
> >> should be required.
> >>
> >
> > Ahhh... you're saying that the address itself (or offset within a page)
> > is the hypercall token, totally separate from IO emulation, and so we
> > could ignore the access size.
>
> No, I'm not being nearly that clever.
I started thinking you weren't, but then I realized you must be working
several levels above me and just forgot to explain... :)
> I was suggesting that hardware virtualization support in future PPC
> systems might contain a mechanism to intercept a guest-mode TLB miss.
> If it did, it would be useful if that guest-mode TLB miss "exit"
> contained extra information somewhere that included the PC of the
> faulting instruction, the address response for the fault, and enough
> information to handle the fault without instruction decoding.
>
> I assume all MMIO comes from the same set of instructions in PPC?
> Something like ld/st instructions? Presumably all you need to know from
> instruction decoding is the destination register and whether it was a
> read or write?
In addition to register source/target, we also need to know the access size of
the memory reference. That information isn't stuffed into registers for us by
hardware, and it's not in published specifications for future hardware.
Now, if you wanted to define a hypercall as a byte access within a particular
4K page, where the register source/target is ignored, that could be
interesting, but I don't know if that's relevant to this "hypercall vs MMIO"
discussion.
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2009-05-12 14:51 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 13:24 [RFC PATCH 0/3] generic hypercall support Gregory Haskins
2009-05-05 13:24 ` [RFC PATCH 1/3] add " Gregory Haskins
2009-05-05 17:03 ` Hollis Blanchard
2009-05-06 13:52 ` Anthony Liguori
2009-05-06 15:16 ` Gregory Haskins
2009-05-06 16:52 ` Arnd Bergmann
2009-05-05 13:24 ` [RFC PATCH 2/3] x86: " Gregory Haskins
2009-05-05 13:24 ` [RFC PATCH 3/3] kvm: add pv_cpu_ops.hypercall support to the guest Gregory Haskins
2009-05-05 13:36 ` [RFC PATCH 0/3] generic hypercall support Avi Kivity
2009-05-05 13:40 ` Gregory Haskins
2009-05-05 14:00 ` Avi Kivity
2009-05-05 14:14 ` Gregory Haskins
2009-05-05 14:21 ` Gregory Haskins
2009-05-05 15:02 ` Avi Kivity
2009-05-05 23:17 ` Chris Wright
2009-05-06 3:51 ` Gregory Haskins
2009-05-06 7:22 ` Chris Wright
2009-05-06 13:17 ` Gregory Haskins
2009-05-06 16:07 ` Chris Wright
2009-05-07 17:03 ` Gregory Haskins
2009-05-07 18:05 ` Avi Kivity
2009-05-07 18:08 ` Gregory Haskins
2009-05-07 18:12 ` Avi Kivity
2009-05-07 18:16 ` Gregory Haskins
2009-05-07 18:24 ` Avi Kivity
2009-05-07 18:37 ` Gregory Haskins
2009-05-07 19:00 ` Avi Kivity
2009-05-07 19:05 ` Gregory Haskins
2009-05-07 19:43 ` Avi Kivity
2009-05-07 20:07 ` Gregory Haskins
2009-05-07 20:15 ` Avi Kivity
2009-05-07 20:26 ` Gregory Haskins
2009-05-08 8:35 ` Avi Kivity
2009-05-08 11:29 ` Gregory Haskins
2009-05-07 19:07 ` Chris Wright
2009-05-07 19:12 ` Gregory Haskins
2009-05-07 19:21 ` Chris Wright
2009-05-07 19:26 ` Avi Kivity
2009-05-07 19:44 ` Avi Kivity
2009-05-07 19:29 ` Gregory Haskins
2009-05-07 20:25 ` Chris Wright
2009-05-07 20:34 ` Gregory Haskins
2009-05-07 20:54 ` Arnd Bergmann
2009-05-07 21:13 ` Gregory Haskins
2009-05-07 21:57 ` Chris Wright
2009-05-07 22:11 ` Arnd Bergmann
2009-05-08 22:33 ` Benjamin Herrenschmidt
2009-05-11 13:01 ` Arnd Bergmann
2009-05-11 13:04 ` Gregory Haskins
2009-05-07 20:00 ` Arnd Bergmann
2009-05-07 20:31 ` Gregory Haskins
2009-05-07 20:42 ` Arnd Bergmann
2009-05-07 20:47 ` Arnd Bergmann
2009-05-07 20:50 ` Chris Wright
2009-05-07 23:35 ` Marcelo Tosatti
2009-05-07 23:43 ` Marcelo Tosatti
2009-05-08 3:17 ` Gregory Haskins
2009-05-08 7:55 ` Avi Kivity
[not found] ` <20090508103253.GC3011@amt.cnet>
2009-05-08 11:37 ` Avi Kivity
2009-05-08 14:35 ` Marcelo Tosatti
2009-05-08 14:45 ` Gregory Haskins
2009-05-08 15:51 ` Marcelo Tosatti
2009-05-08 19:56 ` David S. Ahern
2009-05-08 20:01 ` Gregory Haskins
2009-05-08 23:23 ` David S. Ahern
2009-05-09 8:45 ` Avi Kivity
2009-05-09 11:27 ` Gregory Haskins
2009-05-10 4:27 ` David S. Ahern
2009-05-10 5:24 ` Avi Kivity
2009-05-10 4:24 ` David S. Ahern
2009-05-08 3:13 ` Gregory Haskins
2009-05-08 7:59 ` Avi Kivity
2009-05-08 11:09 ` Gregory Haskins
[not found] ` <20090508104228.GD3011@amt.cnet>
2009-05-08 12:43 ` Gregory Haskins
2009-05-08 15:33 ` Marcelo Tosatti
2009-05-08 19:02 ` Avi Kivity
2009-05-08 16:48 ` Paul E. McKenney
2009-05-08 19:55 ` Gregory Haskins
2009-05-08 14:15 ` Gregory Haskins
2009-05-08 14:53 ` Anthony Liguori
2009-05-08 18:50 ` Avi Kivity
2009-05-08 19:02 ` Anthony Liguori
2009-05-08 19:06 ` Avi Kivity
2009-05-11 16:37 ` Jeremy Fitzhardinge
2009-05-07 12:29 ` Avi Kivity
2009-05-08 14:59 ` Anthony Liguori
2009-05-09 12:01 ` Gregory Haskins
2009-05-10 18:38 ` Anthony Liguori
2009-05-11 13:14 ` Gregory Haskins
2009-05-11 16:35 ` Hollis Blanchard
2009-05-11 17:06 ` Avi Kivity
2009-05-11 17:29 ` Gregory Haskins
2009-05-11 17:53 ` Avi Kivity
2009-05-11 17:51 ` Anthony Liguori
2009-05-11 18:02 ` Avi Kivity
2009-05-11 18:18 ` Anthony Liguori
2009-05-11 17:31 ` Anthony Liguori
2009-05-13 10:53 ` Gregory Haskins
2009-05-13 14:45 ` Gregory Haskins
2009-05-11 16:44 ` Hollis Blanchard
2009-05-11 17:54 ` Anthony Liguori
2009-05-11 19:24 ` PowerPC page faults Hollis Blanchard
2009-05-11 22:17 ` Anthony Liguori
2009-05-12 5:46 ` Liu Yu-B13201
2009-05-12 14:50 ` Hollis Blanchard [this message]
2009-05-06 13:56 ` [RFC PATCH 0/3] generic hypercall support Anthony Liguori
2009-05-06 16:03 ` Gregory Haskins
2009-05-08 8:17 ` Avi Kivity
2009-05-08 15:20 ` Gregory Haskins
2009-05-08 17:00 ` Avi Kivity
2009-05-08 18:55 ` Gregory Haskins
2009-05-08 19:05 ` Anthony Liguori
2009-05-08 19:12 ` Avi Kivity
2009-05-08 19:59 ` Gregory Haskins
2009-05-10 9:59 ` Avi Kivity
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=200905120950.57118.hollisb@us.ibm.com \
--to=hollisb@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=ghaskins@novell.com \
--cc=gregory.haskins@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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