From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWEXb-0003OL-8y for qemu-devel@nongnu.org; Tue, 24 Jan 2017 22:46:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cWEXW-0007E4-Ew for qemu-devel@nongnu.org; Tue, 24 Jan 2017 22:46:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45258) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cWEXW-0007De-7A for qemu-devel@nongnu.org; Tue, 24 Jan 2017 22:46:30 -0500 Date: Wed, 25 Jan 2017 11:46:23 +0800 From: Peter Xu Message-ID: <20170125034623.GA5151@pxdev.xzpeter.org> References: <1484917736-32056-1-git-send-email-peterx@redhat.com> <1484917736-32056-17-git-send-email-peterx@redhat.com> <20170124045242.GM26526@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v4 16/20] intel_iommu: do replay when context invalidate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: tianyu.lan@intel.com, kevin.tian@intel.com, mst@redhat.com, jan.kiszka@siemens.com, bd.aviv@gmail.com, qemu-devel@nongnu.org, alex.williamson@redhat.com On Wed, Jan 25, 2017 at 11:09:39AM +0800, Jason Wang wrote: >=20 >=20 > On 2017=E5=B9=B401=E6=9C=8824=E6=97=A5 12:52, Peter Xu wrote: > >On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: > >> > >>On 2017=E5=B9=B401=E6=9C=8820=E6=97=A5 21:08, Peter Xu wrote: > >>>Before this one we only invalidate context cache when we receive con= text > >>>entry invalidations. However it's possible that the invalidation als= o > >>>contains a domain switch (only if cache-mode is enabled for vIOMMU).= In > >>>that case we need to notify all the registered components about the = new > >>>mapping. > >>> > >>>Signed-off-by: Peter Xu > >>>--- > >>> hw/i386/intel_iommu.c | 10 ++++++++++ > >>> 1 file changed, 10 insertions(+) > >>> > >>>diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > >>>index f9c5142..4b08b4d 100644 > >>>--- a/hw/i386/intel_iommu.c > >>>+++ b/hw/i386/intel_iommu.c > >>>@@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(Int= elIOMMUState *s, > >>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(d= evfn_it), > >>> VTD_PCI_FUNC(devfn_it= )); > >>> vtd_as->context_cache_entry.context_cache_gen =3D = 0; > >>>+ /* > >>>+ * So a device is moving out of (or moving into) a > >>>+ * domain, a replay() suites here to notify all the > >>>+ * IOMMU_NOTIFIER_MAP registers about this change. > >>>+ * This won't bring bad even if we have no such > >>>+ * notifier registered - the IOMMU notification > >>>+ * framework will skip MAP notifications if that > >>>+ * happened. > >>>+ */ > >>>+ memory_region_iommu_replay_all(&vtd_as->iommu); > >>DSI and GLOBAL questions come back again or no need to care about the= m :) ? > >DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 > >in my next post). Is that what you mean above? >=20 > Seems not, I mean DSI/GLOBAL for context cache invalidation instead of = IOTLB > :) Yes, I should possibly do the same thing for context cache global invalidations. IIUC context global invalidation should be a superset of iotlb invalidation, so maybe I'll add one more patch to call iotlb invalidation in context invalidation as well. Kevin/others, please correct me if I misunderstood the spec. Thanks, -- peterx