From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3mgW-0007N2-3H for qemu-devel@nongnu.org; Wed, 14 Sep 2011 06:27:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3mgV-0007uQ-3o for qemu-devel@nongnu.org; Wed, 14 Sep 2011 06:27:16 -0400 Received: from thoth.sbs.de ([192.35.17.2]:23297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3mgU-0007uM-KT for qemu-devel@nongnu.org; Wed, 14 Sep 2011 06:27:15 -0400 Message-ID: <4E708180.1050201@siemens.com> Date: Wed, 14 Sep 2011 12:27:12 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1315992222-24069-1-git-send-email-avi@redhat.com> <4E7078B4.6020203@redhat.com> In-Reply-To: <4E7078B4.6020203@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/3] Memory API mutators List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , "qemu-devel@nongnu.org" On 2011-09-14 11:49, Avi Kivity wrote: > Jan, too, was interested in this. > > On 09/14/2011 12:23 PM, Avi Kivity wrote: >> This patchset introduces memory_region_set_enabled() and >> memory_region_set_address() to avoid the requirement on memory >> routers to track the internal state of the memory API (so they know >> whether they need to add or remove a region). Instead, they can >> simply copy the state of the region from the guest-exposed register >> to the memory core, via the new mutator functions. >> >> Please review. Do we need a memory_region_set_size() as well? Do we want >> >> memory_region_set_attributes(mr, >> MR_ATTR_ENABLED | MR_ATTR_SIZE, >> (MemoryRegionAttributes) { >> .enabled = s->enabled, >> .address = s->addr, >> }); >> >> ? >> >> Avi Kivity (3): >> memory: introduce memory_region_set_enabled() >> memory: introduce memory_region_set_address() >> memory: optimize empty transactions due to mutators >> >> memory.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------- >> memory.h | 28 +++++++++++++++++++++++++++ >> 2 files changed, 82 insertions(+), 10 deletions(-) >> Whatever the outcome is (tons of memory_region_set/get_X functions or huge attribute structures + set/get_attributes), it should be consistent for all attributes of a memory region. And there should be only one way of doing this. I think the decision multiple set/get vs. attribute struct depends on some (estimated) usage stats: How many call sites will access multiple attributes in one run and how may will only manipulate a single? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux