On 10/02/2009 02:32 AM, Benjamin Herrenschmidt wrote:
On Wed, 2009-09-30 at 11:24 +0200, Avi Kivity wrote:
But writing those registers often has side effects. For example,
enabling interrupts should also inject an interrupt when one is
pending. On x86 we have the same problem with the TPR on Windows XP, so
we copy it to the guest on entry (along with the pending interrupt
state) and back to the host on exit. The guest uses an atomic operation
to change the TPR and read pending interrupt information, and if an
interrupt becomes unmasked, it calls a hypercall to trigger it.
Presumably you'll be doing something similar?
In any case, I recommend keeping fine-grained control over those bits so
they can be enabled/disabled/expanded as needed.
Sure, for those who have side-effects, special care must be taken,
either with PV tricks as Alex suggested in another reply, or by
emulation.
But for example, pretty much every time the MSR is written, it's also
previously -read-. If we keep a shadow of the guest MSR in the "magic
page", then we can already half the number of emulation traps simply
by having the guest read from there instead, and still trap on writes.
Those reads don't have side effects.
So these MSRs can be modified by the hypervisor? Otherwise you'd cache
them in the guest with no hypervisor involvement, right? (just making
sure :)
There's also a bunch of SPRs that don't have a direct side effect such
as the SRRs and SPRGs which are heavily used for exception entry and
exit. The former are storage for the PC and MSR values for a subsequent
rfi instruction (return from interrupt) and the later are just general
purpose storage for the kernel to save a few GPRs into in the exception
handling code.
By replacing these by, for example, absolute load/stores in a magic
page mapped differently per-CPU (one trick we have in mind) we can
very significantly speed up the guest kernel exception entry and exit,
and this is without dealing with side effects.
As Alex mention, we can from there try to go further for things like
MSR changes, but you are right that this needs to be done more
carefully.
Thanks for the explanations.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
