From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 4/4] arm/arm64: KVM: use kernel mapping to perform
 invalidation on page fault
Date: Fri, 9 Jan 2015 13:50:36 +0100
Message-ID: <20150109125036.GS21092@cbox>
References: <1420718349-24152-1-git-send-email-marc.zyngier@arm.com>
 <1420718349-24152-5-git-send-email-marc.zyngier@arm.com>
 <CAFEAcA8s0JD04=3-H74fG3a97f+PCQj7WWuzXCm8svTk8j4VYw@mail.gmail.com>
 <54AE811F.4020104@arm.com>
 <CAFEAcA9s9-x+aodi0NgWxx2CjdTf8BRfkMkVKCv5JQV0TaU6EA@mail.gmail.com>
 <54AE9D0F.3060002@arm.com>
 <CAFEAcA_9Dh_SWGy+r3ZY2r+r9T_OH0SiiPQm7pzq6_eGYPcJSA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	kvm-devel <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-lb0-f169.google.com ([209.85.217.169]:52367 "EHLO
	mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754924AbbAIMuQ (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 9 Jan 2015 07:50:16 -0500
Received: by mail-lb0-f169.google.com with SMTP id p9so7903462lbv.0
        for <kvm@vger.kernel.org>; Fri, 09 Jan 2015 04:50:14 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <CAFEAcA_9Dh_SWGy+r3ZY2r+r9T_OH0SiiPQm7pzq6_eGYPcJSA@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Jan 08, 2015 at 03:21:50PM +0000, Peter Maydell wrote:
> On 8 January 2015 at 15:06, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 08/01/15 13:16, Peter Maydell wrote:
> >>> ASID cached VIVT icaches are also VMID tagged. It is thus impossible for
> >>> stale cache lines to come with a new page. And if by synchronizing the
> >>> caches you obtain a different instruction stream, it means you've
> >>> restored the wrong page.
> >>
> >> ...is that true even if the dirty data in the dcache comes from
> >> the userspace process doing DMA or writing the initial boot
> >> image or whatever?
> >
> > We perform this on a page that is being brought in stage-2. Two cases:
> >
> > - This is a page is mapped for the first time: the icache should be
> > invalid for this page (the guest should have invalidated it the first
> > place),
> 
> If this is the first instruction in the guest (ie we've just
> (warm) reset the VM and are running the kernel as loaded into the guest
> by QEMU/kvmtool) then the guest can't have invalidated the icache,
> and QEMU can't do the invalidate because it doesn't have the vaddr
> and VMID of the guest.
> 
The guest must clean its icache before turning on the MMU, no?

Whenever we reuse a VMID (rollover), we flush the entire icache for that
vmid.

-Christoffer