From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaqdf-0005v3-Mn for qemu-devel@nongnu.org; Tue, 01 Mar 2016 15:11:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaqdc-0003L3-GM for qemu-devel@nongnu.org; Tue, 01 Mar 2016 15:11:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaqdc-0003KK-Aq for qemu-devel@nongnu.org; Tue, 01 Mar 2016 15:11:20 -0500 Date: Tue, 1 Mar 2016 22:11:16 +0200 From: "Michael S. Tsirkin" Message-ID: <20160301220139-mutt-send-email-mst@redhat.com> References: <1456078260-6669-1-git-send-email-davidkiarie4@gmail.com> <20160301134419-mutt-send-email-mst@redhat.com> <56D59DA3.3040002@siemens.com> <56D5A069.9030004@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D5A069.9030004@siemens.com> Subject: Re: [Qemu-devel] [V6 0/4] AMD IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: valentine.sinitsyn@gmail.com, marcel@redhat.com, David Kiarie , qemu-devel@nongnu.org On Tue, Mar 01, 2016 at 03:00:09PM +0100, Jan Kiszka wrote: > On 2016-03-01 14:48, Jan Kiszka wrote: > > There is likely no way around write-protecting the IOMMU page tables (in > > KVM mode) once we evaluated and cached them somewhere. > > I mean, when in kvm mode AND having something that caches enabled, of > course. Just write-protecting won't be enough either, since the moment you remove the protection, all bets are off, and if you don't, guest will start from the same point when you re-enter and fault again. What this seems to call for is a new kind of protection where yes PTE is write protected, but instead of making PTE writeable (or killing guest) KVM handles it as an MMIO: emulates the write and then skips the instruction. Emulation can be in kernel, just writing into guest memory on behalf of the guest - with some kind of notifier to flush the vfio cache - or instead it can exit to userspace and have QEMU handle it like MMIO and write into guest memory. > Besides vfio, we also still have the question how to deal with virtio > and DMA remapping, which is probably similarly complicated when some > vhost technology is involved. > > Jan Well, that can limit itself to cache valid entries which is presumably what hardware iommu does. > -- > Siemens AG, Corporate Technology, CT RDA ITP SES-DE > Corporate Competence Center Embedded Linux