Re: Patching guest kernel code for better performance from HOST

[Alexander Graf <agraf@suse.de>]

On 04/05/2011 03:30 PM, Dushyant Bansal wrote:
> On Tuesday 05 April 2011 02:39 PM, Alexander Graf wrote:
>> On 05.04.2011, at 10:59, Dushyant Bansal wrote:
>>
>>> Hi all,
>>>
>>>     I understand that in order to improve performance by reducing vm 
>>> exits, kvm uses one shared page between kvm and guest. Now, guest 
>>> tells the host to map the magic page to '-4096'.
>>>
>>> How does kvm make sure that guest will not use this address ( -4096) 
>>> for other purpose?
>>>
>>> Then, guest itself patches its kernel.
>>> I am trying to patch guest from host. So far, I have tried to patch 
>>> MFMSR instruction. Patching is done when kvm tries to emulate MFMSR. 
>>> Mechanism used to generate new instruction is same as used by guest 
>>> in "arch/powerpc/kernel/kvm.c"
>>>
>>> --- a/arch/powerpc/kvm/book3s_emulate.c
>>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>>> @@ -88,6 +88,23 @@ int kvmppc_core_emulate_op(struct kvm_run *run, 
>>> struct kvm_vcpu *vcpu,
>>>                 case OP_31_XOP_MFMSR:
>>>                         kvmppc_set_gpr(vcpu, get_rt(inst),
>>>                                        vcpu->arch.shared->msr);
>>> +
>>> +                       pc = kvmppc_get_pc(vcpu);
>>> +
>>> +                       //if pte.may_write=false then, kvmppc_st 
>>> will not work
>>> +                       kvmppc_xlate(vcpu,pc,false,&pte);
>>> +                       pte.may_write=true;
>> The pte struct here is write-only from xlate's point of view. Any 
>> modification to it doesn't get reflected to the real translation 
>> layer. But your guess is good, I'd also assume that you're hitting a 
>> read-only page.
> Yes, you are right. Thanks for catching this.
> So, if it is a read-only page, 
> 'kvmppc_st(vcpu,&pc,sizeof(u32),&new_inst,true)' will not write 
> anything. Then, there is no reason for guest to hang. Right?

Oh? It should inject a page fault. Maybe it doesn't, but then it behaves 
badly :).

Either way - just enable the debug tracepoints and check the exits you 
get right after you hit an mfmsr emulation. That should give you hints 
on what's going wrong.


Alex