On 2011-09-28 16:26, Alexander Graf wrote:
On 28.09.2011, at 16:23, Jan Kiszka wrote:Alex, 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, cpu_physical_memory_set_dirty_flags( 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); qemu_put_ram_ptr(ptr); } } 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.
Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
