From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9uoT-0004Bs-78 for qemu-devel@nongnu.org; Mon, 06 Jun 2016 09:43:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9uoO-00023R-6v for qemu-devel@nongnu.org; Mon, 06 Jun 2016 09:43:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9uoO-000234-10 for qemu-devel@nongnu.org; Mon, 06 Jun 2016 09:43:24 -0400 Date: Mon, 6 Jun 2016 21:43:17 +0800 From: Peter Xu Message-ID: <20160606134317.GJ21254@pxdev.xzpeter.org> References: <1463847590-22782-1-git-send-email-bd.aviv@gmail.com> <1463847590-22782-2-git-send-email-bd.aviv@gmail.com> <57408FDB.1010000@web.de> <20160602084439.GB3477@pxdev.xzpeter.org> <20160602070046.761be49c@ul30vt.home> <5750313C.4000709@web.de> <20160606050407.GB21254@pxdev.xzpeter.org> <20160606071141.31d2008e@ul30vt.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160606071141.31d2008e@ul30vt.home> Subject: Re: [Qemu-devel] [PATCH v3 1/3] IOMMU: add VTD_CAP_CM to vIOMMU capability exposed to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Jan Kiszka , "Aviv B.D" , qemu-devel@nongnu.org, "Michael S. Tsirkin" On Mon, Jun 06, 2016 at 07:11:41AM -0600, Alex Williamson wrote: > On Mon, 6 Jun 2016 13:04:07 +0800 > Peter Xu wrote: [...] > > Besides the reason that there might have guests that do not support > > CM=1, will there be performance considerations? When user's > > configuration does not require CM capability (e.g., generic VM > > configuration, without VFIO), shall we allow user to disable the CM > > bit so that we can have better IOMMU performance (avoid extra and > > useless invalidations)? > > With Alexey's proposed patch to have callback ops when the iommu > notifier list adds its first entry and removes its last, any of the > additional overhead to generate notifies when nobody is listening can > be avoided. These same callbacks would be the ones that need to > generate a hw_error if a notifier is added while running in CM=0. Not familar with Alexey's patch, but is that for VFIO only? I mean, if we configured CMbit=1, guest kernel will send invalidation request every time it creates new entries (context entries, or iotlb entries). Even without VFIO notifiers, guest need to trap into QEMU and process the invalidation requests. This is avoidable if we are not using VFIO devices at all (so no need to maintain any mappings), right? If we allow user to specify cmbit={0|1}, user can decide whether he/she would like to take this benefit. Thanks, -- peterx