From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] memory: transaction API Date: Thu, 21 Jul 2011 15:13:14 +0300 Message-ID: <4E2817DA.4030505@redhat.com> References: <1311243679-18403-1-git-send-email-avi@redhat.com> <4E280195.5040003@siemens.com> <4E281609.7090809@redhat.com> <4E2816DE.5010102@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6946 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834Ab1GUMNV (ORCPT ); Thu, 21 Jul 2011 08:13:21 -0400 In-Reply-To: <4E2816DE.5010102@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/21/2011 03:09 PM, Jan Kiszka wrote: > > > > Why? just stick a _begin() and _commit() at the start and end of the > > update_mapping() function. It's an optional API, for simple cases (like > > mapping a BAR) you don't have to use it. > > begin > delete old > free old > create new > add new > end > > vs. > > update > The problem is that "update" can change lots of things. offset, size, whether it's mmio or RAM, read-onlyness, even the wierd things like coalesced mmio. So it's either a function with 324.2 parameters (or a large struct), or it's a series of functions with demarcation as to where the update begins and ends. > > > > > >> Do we have transactional scenarios during runtime where multiple memory > >> regions are reconfigured? > > > > Both cirrus and 440fx PAM, I believe. They don't check for the "no > > change" condition (at least, not completely) and instead override the > > previous mapping. > > That's the job of the memory mapping core IIUC. In my opinion, too. Devices should be dead simple. > But it can only be done > efficiently with an 'update' operation. Why is the transaction API inefficient? AFAICT it accomplishes the same thing. Some cycles are spent on finding out nothing has changed, but that's fine. -- error compiling committee.c: too many arguments to function