Kernel KVM-PPC virtualization development
 help / color / mirror / Atom feed
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 3/6] kvmppc: rewrite guest code - sprg0-3
Date: Tue, 02 Sep 2008 07:30:30 +0000	[thread overview]
Message-ID: <48BCEB96.7040309@linux.vnet.ibm.com> (raw)
In-Reply-To: <1219142205-12062-4-git-send-email-ehrhardt@linux.vnet.ibm.com>

Liu Yu-B13201 wrote:
>> -----Original Message-----
>> From: Christian Ehrhardt [mailto:ehrhardt@linux.vnet.ibm.com] 
>> Sent: Monday, September 01, 2008 8:15 PM
>> To: Liu Yu-B13201
>> Cc: kvm-ppc@vger.kernel.org; hollisb@us.ibm.com
>> Subject: Re: [PATCH 3/6] kvmppc: rewrite guest code - sprg0-3
>>
>>     
>
>   
>>>> +
>>>> +		down_read(&current->mm->mmap_sem);
>>>> +		pcpage = gfn_to_page(vcpu->kvm,
>>>> +				guest_pcaddr >> 
>>>> KVM_PPCPV_MAGIC_PAGE_SHIFT);
>>>> +		up_read(&current->mm->mmap_sem);
>>>> +		if (pcpage = bad_page)
>>>> +			return -EFAULT;
>>>> +
>>>> +		pcmem = kmap_atomic(pcpage, KM_USER0);
>>>> +		if (!pcmem)
>>>> +			return -EFAULT;
>>>> +		pcaddr = ((unsigned long)pcmem
>>>> +				| (vcpu->arch.pc & 
>>>> KVM_PPCPV_MAGIC_PAGE_MASK));
>>>> +		BUG_ON(inst != *((u32 *)pcaddr));
>>>> +		create_instruction(pcaddr, newinst);
>>>> +		kunmap_atomic(pcpage, KM_USER0);
>>>> +	}
>>>>     
>>>>         
>>> I think you are writing new instruction back here.
>>> Why not use kvm_write_guest_page() (kvm_main.c) directly?
>>>   
>>>       
>> hmm I'm exchaning instructions in memory and the "create_instruction" 
>> function I use is exactly doing that.
>> I expect that the kvm function would miss the needed sync 
>> functionality 
>> to ensure that all old code is dropped from the cpu caches. 
>> Well I'm not 
>> an expert in that, I need to look into that.
>>
>>     
>
> It seems there wouldn't be cache consistency problem for PowerPC as long as the memory is updated by processor.
> Btw, where is the definition of create_instruction?
>
>   
-> asm/system.h:521
>>>   
>>>       
>>>> +
>>>> +	return err;
>>>> +}
>>>>  
>>>>  /* XXX to do:
>>>>   * lhax
>>>> @@ -260,6 +415,9 @@
>>>>  	int dcrn;
>>>>  	enum emulation_result emulated = EMULATE_DONE;
>>>>  	int advance = 1;
>>>> +
>>>> +	if (kvmppc_has_pvmem(vcpu) && 
>>>> !kvmppc_pvmem_rewrite_instruction(vcpu))
>>>> +		return EMULATE_DONE;
>>>>     
>>>>         
>>> Rewirting instruction is one-off, so it's not that important to pay
>>> attention to performance.
>>> However, putting rewriting at the beginning of the function 
>>>       
>> add extra
>>     
>>> workload to other emulations.
>>>
>>> How about this way?
>>>
>>> 	int rewrite = 0;
>>>
>>> 	.......
>>> 	case mfspr0:
>>> 		rewrite = 1;
>>> 	......
>>>
>>> 	// at the end of the function
>>> 	if(unlikely(rewrite) && kvmppc_has_pvmem(vcpu))
>>> 		kvmppc_pvmem_rewrite_instruction(vcpu);
>>> 		
>>>   
>>>       
>> This would spread checks with kvmppc_has_pvmem all over the code, 
>> because if we rewrite the instruction it is not allowed to emulate it.
>> On the other hand we could emulate it and change the instruction for 
>> their "next" hit (not jump back to current pc but at pc+4 as it is 
>> emulated).
>> Yeah that could work, and once most rewrite actions are done the 
>> "unlikely" is the right thing because later on we won't hit 
>> it anymore. 
>> That should speed up emulation a bit (not much compared to exit/enter 
>> guest, but it's never wrong to code things performance wise).
>>
>>     
>
> In fact, not only the unlikely thing, I am worried about that
> putting kvmppc_pvmem_rewrite_instruction() at beginning 
> will cosume some time for normal emulations, ( a lot comparisons and jumps)
> especially more and more instructions would be replaced in it in the future.
>
>   
Sure, I think I already got your point. This is what I described with 
"emulate & rewrite it" allowing us to put the 
kvmppc_pvmem_rewrite_instruction() at the end guarded by an additional 
if that will eventually reduce the overhead to nearly zero once the 
trapping code is rewritten.

The code flow I have in mind is that:

emulate instruction
  if this is a rewritable one set flag
increase program counter because instruction is emulated
if unlikely(rewritable) flag is set and kvm_has_pvmem call 
kvmppc_pvmem_rewrite_instruction

-> The next time guest executes that code it will already use the new 
rewritten instruction
-> non rewritable instructions that are emulated don't set the flag and 
therefore don't call kvmppc_pvmem_rewrite_instruction saving overhead

I'll submit an updated patch series somewhen this week. Then you can 
check if I got your hint right :-)

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization


  parent reply	other threads:[~2008-09-02  7:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19 10:36 [PATCH 3/6] kvmppc: rewrite guest code - sprg0-3 ehrhardt
2008-08-20 17:42 ` Hollis Blanchard
2008-08-21 13:19 ` Christian Ehrhardt
2008-08-21 18:54 ` Hollis Blanchard
2008-08-29  2:20 ` Liu Yu
2008-08-29  2:58 ` Liu Yu
2008-09-01 12:15 ` Christian Ehrhardt
2008-09-01 12:26 ` Christian Ehrhardt
2008-09-02  3:02 ` Liu Yu-B13201
2008-09-02  7:30 ` Christian Ehrhardt [this message]
2008-09-16  6:27 ` ehrhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48BCEB96.7040309@linux.vnet.ibm.com \
    --to=ehrhardt@linux.vnet.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox