From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxOhP-0005uk-67 for qemu-devel@nongnu.org; Tue, 26 May 2015 19:55:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxOhK-00005d-6G for qemu-devel@nongnu.org; Tue, 26 May 2015 19:55:55 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:36184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxOhK-00005L-0V for qemu-devel@nongnu.org; Tue, 26 May 2015 19:55:50 -0400 Received: by paza2 with SMTP id a2so95020293paz.3 for ; Tue, 26 May 2015 16:55:48 -0700 (PDT) Message-ID: <556507FD.6060905@ozlabs.ru> Date: Wed, 27 May 2015 09:55:41 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1429964684-23872-1-git-send-email-aik@ozlabs.ru> <55646C18.4000303@redhat.com> <5564750C.8000100@ozlabs.ru> <556475BD.50401@redhat.com> <55647843.4040609@ozlabs.ru> <556479B6.1010501@redhat.com> <55647C75.5000704@ozlabs.ru> <55647D4C.6060008@redhat.com> <55648086.3010804@ozlabs.ru> <55648239.7070905@redhat.com> <20150526145557.4646.3678@loki> <55648A21.50401@redhat.com> <55649612.8070004@ozlabs.ru> <55649677.2090502@redhat.com> In-Reply-To: <55649677.2090502@redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Michael Roth , David Gibson Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf On 05/27/2015 01:51 AM, Paolo Bonzini wrote: > > > On 26/05/2015 17:49, Alexey Kardashevskiy wrote: >>> >>> It's very little used, but that's just because it's not too common. >>> There's nothing wrong with it. :) >>> >>> If you do del/set_size/add, you may want to put a >>> memory_region_transaction_{begin,commit} around the whole dance. >> Here I lost you again :) >> Why? These are IOMMU MRs -> they are dynamic, what will begin()/commit() >> change here? > > If you don't add them, the memory core may create two or three different > flatviews. With begin/commit, it will only do one change. It's just an > optimization. One step back :) Whole dance is what here? There are: 1) del+set_size(0) 2) set_size(not zero)+add 1) and 2) are called in different places, between those the guest get control so I cannot wrap these in begin/commit. If you suggest begin+commit around, for example, 1)- this is just a single call and there be one change to flatview, where many changes may happen? And only the last one is used, right, or there is a list of them somewhere? :) -- Alexey