From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byaDo-0008Ik-Fu for qemu-devel@nongnu.org; Mon, 24 Oct 2016 04:03:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byaDk-0006fO-Im for qemu-devel@nongnu.org; Mon, 24 Oct 2016 04:03:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48872) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1byaDk-0006f4-De for qemu-devel@nongnu.org; Mon, 24 Oct 2016 04:03:00 -0400 Date: Mon, 24 Oct 2016 16:02:57 +0800 From: Peter Xu Message-ID: <20161024080257.GU15168@pxdev.xzpeter.org> References: <1476719064-9242-1-git-send-email-bd.aviv@gmail.com> <1476719064-9242-4-git-send-email-bd.aviv@gmail.com> <20161019093314.GC15168@pxdev.xzpeter.org> <20161021035700.GO15168@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v4 RESEND 3/3] IOMMU: enable intel_iommu map and unmap notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Aviv B.D." Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" , Alex Williamson , Jan Kiszka On Mon, Oct 24, 2016 at 10:53:01AM +0300, Aviv B.D. wrote: [...] > This was my first algorithm, but VFIO do not support remapping of mapped > page. > Before each MAP operation in VFIO one must do unmap, and therefore I'm > sending > the unmap notifications blindly before. > I can rearrange my code closer to your suggestion. If so, I would suggest we solve the real problem first: we should not notify VFIO twice on map(), but only once. IMO either Alex's or David's suggestion (in the other mail) is a good start. > > > > > > This is to follow your logic. I don't know whether this is efficient > > enough, maybe good for the first version. The problem is, when you > > call translate(), you will need to go over the page every time from > > root dir. A faster way may be: provide a function to walk specific > > address range. If you are going to implement the replay logic that > > Alex/David has mentioned, maybe that will help too (walk over the > > whole 64bit range). > > > > Interesting idea, but I prefer to add it in separate patch set after this > one committed, if it's OK. Sure. -- peterx