From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cW2P0-0000hE-4p for qemu-devel@nongnu.org; Tue, 24 Jan 2017 09:48:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cW2Oz-0001Jm-5L for qemu-devel@nongnu.org; Tue, 24 Jan 2017 09:48:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46370) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cW2Oy-0001JK-WA for qemu-devel@nongnu.org; Tue, 24 Jan 2017 09:48:53 -0500 Date: Tue, 24 Jan 2017 16:48:49 +0200 From: "Michael S. Tsirkin" Message-ID: <20170124164751-mutt-send-email-mst@kernel.org> References: <1485253571-19058-1-git-send-email-peterx@redhat.com> <20170124114910.GD16400@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170124114910.GD16400@pxdev.xzpeter.org> Subject: Re: [Qemu-devel] [PATCH v5 00/18] VT-d: vfio enablement and misc enhances List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu Cc: qemu-devel@nongnu.org, tianyu.lan@intel.com, kevin.tian@intel.com, jan.kiszka@siemens.com, jasowang@redhat.com, alex.williamson@redhat.com, bd.aviv@gmail.com On Tue, Jan 24, 2017 at 07:49:10PM +0800, Peter Xu wrote: > On Tue, Jan 24, 2017 at 06:25:53PM +0800, Peter Xu wrote: > > This is v5 of vt-d vfio enablement series. > > > > Most of the changes in v5 is not functionally, but related to > > comments, error_report()s, debugging, squashing patches, etc. (which > > are confirmed changes in v4), besides a tiny tweak when unmapping a > > whole address space (please see below changelog). There are still > > discussions in v4 thread, we can just continue there (or here), and > > from this version I'll remove RFC tag. > > > > I didn't rebase to master since current master failed to build on my > > laptop (with a "vl.c/hax..." error), however this series should be > > okay to be applied cleanly upon it. > > Sorry I forgot to append the todo list (please help adding in in case > I missed anything): > > - don't need to notify IOTLB (psi/gsi/global) invalidations to devices > that with ATS enabled > - investigate when guest map page while mask contains existing mapped > pages (e.g. map 12k-16k first, then map 0-12k) > - coalesce unmap during page walk (currently, we send it once per > page) > - when do PSI for unmap, whether we can send one notify directly > instead of walking over the page table? > > Above does not contain those that are still during discussion. And, > some of the entries still need tests to further prove it's > feasibility. > > Thanks, > > -- peterx While valid I don't think above need to block merging. -- MST