[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1242069898.29194.99.camel@slate.austin.ibm.com>
Date: Mon, 11 May 2009 14:24:58 -0500
From: Hollis Blanchard <hollisb@...ibm.com>
To: Anthony Liguori <anthony@...emonkey.ws>
Cc: Gregory Haskins <ghaskins@...ell.com>, Avi Kivity <avi@...hat.com>,
Chris Wright <chrisw@...s-sol.org>,
Gregory Haskins <gregory.haskins@...il.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: PowerPC page faults
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. I guess it looks like this:
page fault vector:
if (faulting_address & PAGE_MASK) == vcpu->hcall_page
handle_hcall(faulting_address & ~PAGE_MASK)
else
if (faulting_address is IO)
emulate_io(faulting_address)
else
handle_pagefault(faulting_address)
Testing for hypercalls in the page fault handler path would add some
overhead, and on processors with software-managed TLBs, the page fault
path is *very* hot. Implementing the above pseudocode wouldn't be ideal,
especially because Power processors with hardware virtualization support
have a separate vector for hypercalls. However, I suspect it wouldn't be
a show-stopper from a performance point of view.
Note that other Power virtualization solutions (hypervisors from IBM,
Sony, and Toshiba) use the dedicated hypercall instruction and interrupt
vector, which after all is how the hardware was designed. To my
knowledge, they also don't do IO emulation, so they avoid both
conditionals in the above psuedocode.
--
Hollis Blanchard
IBM Linux Technology Center
--
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