From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm: Role of flush_icache_range on PPC Date: Wed, 28 Sep 2011 16:45:32 +0200 Message-ID: <4E83330C.2080901@siemens.com> References: <4E832DE3.40503@siemens.com> <5B15DB32-18DF-4637-AD37-4BE652A031E3@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm , qemu-devel Developers , "qemu-ppc@nongnu.org" , Benjamin Herrenschmidt , David Gibson To: Alexander Graf Return-path: Received: from goliath.siemens.de ([192.35.17.28]:19817 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754591Ab1I1Opu (ORCPT ); Wed, 28 Sep 2011 10:45:50 -0400 In-Reply-To: <5B15DB32-18DF-4637-AD37-4BE652A031E3@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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