Re: [PATCH 00/27] Add KVM support for Book3s_64 (PPC64) hosts v4

[Avi Kivity <avi@redhat.com>]

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.