From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROCb5-000487-VL for qemu-devel@nongnu.org; Wed, 09 Nov 2011 13:10:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROCb3-0006la-Ti for qemu-devel@nongnu.org; Wed, 09 Nov 2011 13:10:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROCb3-0006l4-MF for qemu-devel@nongnu.org; Wed, 09 Nov 2011 13:10:01 -0500 Message-ID: <4EBAC1F2.9040502@redhat.com> Date: Wed, 09 Nov 2011 20:09:54 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1319540983-4248-1-git-send-email-benoit.canet@gmail.com> <1319540983-4248-5-git-send-email-benoit.canet@gmail.com> <4EB8CD52.1000008@redhat.com> <4EB91EDE.7070909@redhat.com> <4EB922DD.6040309@redhat.com> <4EB933BE.7080503@codemonkey.ws> <4EB93ED9.6060105@redhat.com> <4EB944EE.9090304@codemonkey.ws> <4EB9477D.5010804@redhat.com> <4EB94B9F.5040102@codemonkey.ws> <4EB964AC.6000605@redhat.com> <4EBA90D8.8040707@codemonkey.ws> <4EBA96BD.5050904@redhat.com> <4EBAA0EC.6030409@codemonkey.ws> <4EBAA2AE.5070003@redhat.com> <4EBABBD1.3000206@codemonkey.ws> In-Reply-To: <4EBABBD1.3000206@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , qemu-devel@nongnu.org, quintela@redhat.com On 11/09/2011 07:43 PM, Anthony Liguori wrote: >> Every MemoryRegion field in qemu today is either immutable or slaved to >> another register. We could have a system to annotate every field, but >> it's pointless. > > > If I'm writing a device and doing save/restore and I happen to use a > MemoryRegion, how do I determine that every field is either immutable > or slaved? In general 'return true' should work. I have a hard time imagining a device where this doesn't hold. If all memory API functions are called with parameters that are functions of the state and only the state, you're good. >> The memory/mutators branch simplifies it by eliminating pseudo state >> like flash_mapped. > > > They just moved the derived state into the MemoryRegion, no? > They do not. We had this state in three places. memory/mutators folds ->flash_mapped and the MemoryRegion equivalent; they both still mirror the real device register. If we had an Observable interface for Registers, then we could make any write to the Register automatically update the MemoryRegion; as it is, we have to call device_update_mapping() after every write. >> Yes, ISR fields often have it (like virtio). > > Yes, but virtio-pci was a very special case to avoid taking an extra > exit. > > Do you know of any other than virtio-pci? All the ones I can think of > (RTC, Serial, etc.) are cleared with a write. Can't think of any offhand, but see http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=5724. Anyway, if something turns out not to be useful, we don't have to keep it in the core. >> This style of code really wants lambdas. Without them, we have 4-5 >> lines of boilerplate for each callback. Even then, it's worthwhile IMO >> (and many callbacks can be avoided, both read and write, or merged into >> a device_update_mapping or device_update_irq read-all-state style >> functions). > > > Yeah, I looked at this but wasn't happy with the results. In > practice, many devices end up implementing non-trivial logic when > register values change. > > What I was really interested in was coming up with a way to get really > high quality tracing of device register accesses. A Register can still dispatch to a common dispatch function. Another thing I'm thinking of is wrapping addr/size/value in a Transaction object, to keep the signatures trim. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.