From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9Chy-0004aT-1u for qemu-devel@nongnu.org; Tue, 22 Nov 2016 10:10:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9Cht-0004nM-42 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 10:10:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55054) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9Chs-0004mY-UD for qemu-devel@nongnu.org; Tue, 22 Nov 2016 10:10:01 -0500 Date: Tue, 22 Nov 2016 17:09:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20161122170734-mutt-send-email-mst@kernel.org> References: <1478603064-32562-1-git-send-email-bd.aviv@gmail.com> <1478603064-32562-2-git-send-email-bd.aviv@gmail.com> <20161109235951-mutt-send-email-mst@kernel.org> <41326d6d-7cdd-afba-ca13-8063e077bfbd@redhat.com> <20161111053836-mutt-send-email-mst@kernel.org> <3e4c0566-d450-63a1-6f9e-e215ed77f4f9@redhat.com> <20161121153426-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v6 1/3] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: Jan Kiszka , "Aviv B.D" , Alex Williamson , qemu-devel@nongnu.org, Peter Xu On Tue, Nov 22, 2016 at 12:11:21PM +0800, Jason Wang wrote: > Yes, that's the interesting point. The fault is not guaranteed but > conditional. And we have similar issue for IEC. > > So in conclusion (since I can't find a hardware IOMMU that have CM set): > > 1) If we don't cache fault conditions, we are still in question that whether > it was spec compatible. > 2) If we do cache fault conditions, we are 100% sure it was spec compatible. > > Consider 2) is not complicated, we'd better do it I believe? > > Thanks IMO it's just a confusing jargon used by intel architects. CM is there exactly so you can shadow the tables, but they were trying hard to use wording that also makes sense to hardware/driver developers. Nothing to worry about. -- MST