[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] qemu-kvm: Role of flush_icache_range on PPC

From: Jan Kiszka
Subject: Re: [Qemu-ppc] qemu-kvm: Role of flush_icache_range on PPC
Date: Wed, 28 Sep 2011 16:45:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-09-28 16:26, Alexander Graf wrote:

On 28.09.2011, at 16:23, Jan Kiszka wrote:


we have this diff in qemu-kvm:

diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, 
uint8_t *buf,
                         addr1, (0xff&  ~CODE_DIRTY_FLAG));
+               /* qemu doesn't execute guest code directly, but kvm does
+                  therefore flush instruction caches */
+               if (kvm_enabled())
+                   flush_icache_range((unsigned long)ptr,
+                                      ((unsigned long)ptr)+l);
         } else {

flush_icache_range() is doing something only on PPC hosts. So do we need
this upstream?

This makes sure that when device emulation overwrites code that is already 
present in the cache of a CPU, it gets flushed from the icache. I'm fairly sure 
we want that :). But let's ask Ben and David as well.

/me wondered which write scenario precisely needs this. It could only be something synchronous /wrt to some VCPU. Which operations could trigger such a write? Does PPC inject software breakpoints in form of trap operations or so?

Mmm, according to our ancient recordings, the hunk above was once introduced for the sake of IA64: 9dc99a2823. I skipped it in my removal patch as it has some non-IA64 effect, at least potentially.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]