From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxebx-0001hZ-Ik for qemu-devel@nongnu.org; Mon, 10 Apr 2017 15:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cxebt-0004jB-KO for qemu-devel@nongnu.org; Mon, 10 Apr 2017 15:04:25 -0400 Received: from mail.kernel.org ([198.145.29.136]:54838) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cxebt-0004i4-En for qemu-devel@nongnu.org; Mon, 10 Apr 2017 15:04:21 -0400 Date: Mon, 10 Apr 2017 12:04:15 -0700 (PDT) From: Stefano Stabellini In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: hrg Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org, jun.nakajima@intel.com, agraf@suse.de, sstabellini@kernel.org, xen-devel@lists.xenproject.org, xen-devel@lists.xen.org, "Herongguang (Stephen)" , wangxinxin.wang@huawei.com On Mon, 10 Apr 2017, hrg wrote: > On Sun, Apr 9, 2017 at 11:55 PM, hrg wrote: > > On Sun, Apr 9, 2017 at 11:52 PM, hrg wrote: > >> Hi, > >> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->nex= t > >> instead of first level entry (if map to rom other than guest memory > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned > >> out memory, qemu did not invalidate cache entries in linked > >> list(entry->next), so when VM balloon back in memory, gfns probably > >> mapped to different mfns, thus if guest asks device to DMA to these > >> GPA, qemu may DMA to stale MFNs. > >> > >> So I think in xen_invalidate_map_cache() linked lists should also be > >> checked and invalidated. > >> > >> What=E2=80=99s your opinion? Is this a bug? Is my analyze correct? Yes, you are right. We need to go through the list for each element of the array in xen_invalidate_map_cache. Can you come up with a patch? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache? Date: Mon, 10 Apr 2017 12:04:15 -0700 (PDT) Message-ID: References: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1306683928-1491851056=:2759" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: hrg Cc: xen-devel@lists.xensource.com, wangxinxin.wang@huawei.com, qemu-devel@nongnu.org, agraf@suse.de, sstabellini@kernel.org, jun.nakajima@intel.com, anthony.perard@citrix.com, xen-devel@lists.xenproject.org, xen-devel@lists.xen.org, "Herongguang (Stephen)" List-Id: xen-devel@lists.xenproject.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1306683928-1491851056=:2759 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 10 Apr 2017, hrg wrote: > On Sun, Apr 9, 2017 at 11:55 PM, hrg wrote: > > On Sun, Apr 9, 2017 at 11:52 PM, hrg wrote: > >> Hi, > >> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next > >> instead of first level entry (if map to rom other than guest memory > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned > >> out memory, qemu did not invalidate cache entries in linked > >> list(entry->next), so when VM balloon back in memory, gfns probably > >> mapped to different mfns, thus if guest asks device to DMA to these > >> GPA, qemu may DMA to stale MFNs. > >> > >> So I think in xen_invalidate_map_cache() linked lists should also be > >> checked and invalidated. > >> > >> What’s your opinion? Is this a bug? Is my analyze correct? Yes, you are right. We need to go through the list for each element of the array in xen_invalidate_map_cache. Can you come up with a patch? --8323329-1306683928-1491851056=:2759 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --8323329-1306683928-1491851056=:2759--