From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/5] KVM: PPC: Book3S HV: Handle memory slot deletion and modification correctly Date: Sun, 19 Aug 2012 12:39:10 +0300 Message-ID: <5030B43E.5090206@redhat.com> References: <20120810003439.GB26420@bloggs.ozlabs.ibm.com> <20120810012532.GA15142@amt.cnet> <20120810110909.fd044ae1.yoshikawa.takuya@oss.ntt.co.jp> <20120810183553.GA16345@amt.cnet> <20120811003754.GA6016@bloggs.ozlabs.ibm.com> <20120813163411.GA22134@amt.cnet> <20120813220450.GB15395@amt.cnet> <502B6B2D.2060906@redhat.com> <20120815175920.GB18452@amt.cnet> <1345187178.11751.49.camel@pasglop> <20120817183939.GA26687@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benjamin Herrenschmidt , Paul Mackerras , Gleb Natapov , Alex Williamson , Takuya Yoshikawa , Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: In-Reply-To: <20120817183939.GA26687@amt.cnet> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 08/17/2012 09:39 PM, Marcelo Tosatti wrote: > > Yes. Well, Avi mentioned earlier that there are users for change of GPA > base. But, if my understanding is correct, the code that emulates > change of BAR in QEMU is: > > /* now do the real mapping */ > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_del_subregion(r->address_space, r->memory); > } > r->addr = new_addr; > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_add_subregion_overlap(r->address_space, > r->addr, r->memory, 1); > > These translate to two kvm_set_user_memory ioctls. Not directly. These functions change a qemu-internal memory map, which is then transferred to kvm. Those two calls might be in a transaction (they aren't now), in which case the memory map update is atomic. So indeed we issue two ioctls now, but that's a side effect of the implementation, not related to those two calls being separate. > > "> Without taking into consideration backwards compatibility, userspace > > can first delete the slot and later create a new one. > > Current qemu will in fact do that. Not sure about older ones. > " > > Avi, where it does that? By "that" I meant first deleting the first slot and then creating a new one. -- error compiling committee.c: too many arguments to function