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. 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. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
