From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfkoY-0001JO-13 for qemu-devel@nongnu.org; Fri, 02 Sep 2016 05:31:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfkoT-0005Ie-OO for qemu-devel@nongnu.org; Fri, 02 Sep 2016 05:31:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfkoT-0005IX-GL for qemu-devel@nongnu.org; Fri, 02 Sep 2016 05:31:05 -0400 Date: Fri, 2 Sep 2016 17:31:00 +0800 From: Peter Xu Message-ID: <20160902093100.GD18496@pxdev.xzpeter.org> References: <76fb2f05-4f9c-3e91-d301-3e0a6d4cabaf@redhat.com> <20160901022929.GA3558@pxdev.xzpeter.org> <20160831204342.77fbe728@t450s.home> <20160901035848.GC3558@pxdev.xzpeter.org> <20160902141504.05950823@voom.fritz.box> <20160902053733.GB10595@pxdev.xzpeter.org> <20160902161014.7e53530b@voom.fritz.box> <20160902061557.GB18496@pxdev.xzpeter.org> <20160902061847.GC18496@pxdev.xzpeter.org> <20160902170028.48a01768@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160902170028.48a01768@voom.fritz.box> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for 2.8 10/11] Revert "intel_iommu: Throw hw_error on notify_started" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Alex Williamson , Jason Wang , mst@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, cornelia.huck@de.ibm.com, wexu@redhat.com, vkaplans@redhat.com On Fri, Sep 02, 2016 at 05:00:28PM +1000, David Gibson wrote: > On Fri, 2 Sep 2016 14:18:47 +0800 > Peter Xu wrote: >=20 > > On Fri, Sep 02, 2016 at 02:15:57PM +0800, Peter Xu wrote: > > > > No, implement the full notifier, and a listener which only wants = the > > > > invalidates can just ignore callbacks which add new mappings. > > > >=20 > > > > As I said, you'll need this to get VFIO working with vIOMMU which > > > > someone is bound to want soon enough anyway. =20 > > >=20 > > > But for vhost cases, we do not need CM bit enabled. That might be t= he > > > difference? > > >=20 > > > I think we need to have vhost working even without CM bit. Device > > > IOTLB should be able to achieve that. =20 > >=20 > > The problem is that, IMHO we should be very careful on enabling CM > > bit. After enabling it, system might get slower (though I haven't > > tried it yet), or even very slow? So maybe we will only enable it whe= n > > really needed (e.g., to do device passthrough and build the shadow > > table). >=20 > Um.. what's the CM bit and what does it have to do with anything? It's used to trace guest IO address space mapping changes. Pasted from VT-d spec chap 6.1: The Caching Mode (CM) field in Capability Register indicates if the hardware implementation caches not-present or erroneous translation-structure entries. When the CM field is reported as Set, any software updates to any remapping structures (including updates to not-present entries or present entries whose programming resulted in translation faults) requires explicit invalidation of the caches. Hardware implementations of this architecture must support operation corresponding to CM=3D0. Operation corresponding to CM=3D1 may be supported by software implementations (emulation) of this architecture for efficient virtualization of remapping hardware. Software managing remapping hardware should be written to handle both caching modes. Software implementations virtualizing the remapping architecture (such as a VMM emulating remapping hardware to an operating system running within a guest partition) may report CM=3D1 to efficiently virtualize the hardware. Software virtualization typically requires the guest remapping structures to be shadowed in the host. Reporting the Caching Mode as Set for the virtual hardware requires the guest software to explicitly issue invalidation operations on the virtual hardware for any/all updates to the guest remapping structures. The virtualizing software may trap these guest invalidation operations to keep the shadow translation structures consistent to guest translation structure modifications, without resorting to other less efficient techniques (such as write-protecting the guest translation structures through the processor=E2=80=99s paging facility). Currently it is not supported for Intel vIOMMUs. -- peterx