From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxH70-0006gl-PA for qemu-devel@nongnu.org; Tue, 26 May 2015 11:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxH6v-0002In-Qu for qemu-devel@nongnu.org; Tue, 26 May 2015 11:49:50 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:35919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxH6v-0002If-Md for qemu-devel@nongnu.org; Tue, 26 May 2015 11:49:45 -0400 Received: by paza2 with SMTP id a2so86525618paz.3 for ; Tue, 26 May 2015 08:49:45 -0700 (PDT) Message-ID: <55649612.8070004@ozlabs.ru> Date: Wed, 27 May 2015 01:49:38 +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> In-Reply-To: <55648A21.50401@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 12:58 AM, Paolo Bonzini wrote: > > > On 26/05/2015 16:55, Michael Roth wrote: >>> That's not a problem, there's memory_region_set_size for that. >> >> What on earth, I could've sworn I looked for this... yes I think that >> would solve the issue here. mr_add/mr_del can handle the change in >> offsets, set size can deal with the change and size, and we can then >> move to using an MR allocated at IOMMU creation time. > > 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? -- Alexey