From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Subject: Re: qemu-kvm: Role of flush_icache_range on PPC
Date: Wed, 28 Sep 2011 16:20:05 -0500
Message-ID: <4E838F85.6070008@freescale.com>
References: <4E832DE3.40503@siemens.com>	
	<5B15DB32-18DF-4637-AD37-4BE652A031E3@suse.de>	
	<4E83330C.2080901@siemens.com> <4E8358FD.6030408@freescale.com>
	<1317243755.29415.99.camel@pasglop>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: kvm <kvm@vger.kernel.org>, qemu-devel Developers <qemu-devel@nongnu.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Alexander Graf <agraf@suse.de>, David Gibson <dwg@au1.ibm.com>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <1317243755.29415.99.camel@pasglop>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: </archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On 09/28/2011 04:02 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-09-28 at 12:27 -0500, Scott Wood wrote:
> 
>> Why would it need to be synchronous?  Even if it's asynchronous emulated
>> DMA, we don't want it sitting around only in a data cache that
>> instruction fetches won't snoop.
> 
> Except that this is exactly what happens on real HW :-)

DMA does not normally go straight to data cache, at least on hardware
I'm familiar with.

> The guest will do the necessary invalidations. DMA doesn't keep the
> icache coherent on HW, why should it on kvm/qemu ?

Sure, if there might be stale stuff in the icache, the guest will need
to invalidate that.  But when running on real hardware, an OS does not
need to flush it out of data cache after a DMA transaction[1].  So
technically we just want a flush_dcache_range() for DMA.

It's moot unless we can distinguish DMA writes from breakpoint writes,
though.

-Scott

[1] Most OSes may do this anyway, to avoid needing to special case when
the dirtying is done entirely by DMA (or to avoid making assumptions
that could be broken by weird hardware), but that doesn't mean QEMU/KVM
should assume that -- maybe unless there's enough performance to be
gained by looking like the aforementioned "weird hardware" in certain
configurations.