From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] memory: transaction API Date: Thu, 21 Jul 2011 12:38:13 +0200 Message-ID: <4E280195.5040003@siemens.com> References: <1311243679-18403-1-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:21672 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752003Ab1GUKiV (ORCPT ); Thu, 21 Jul 2011 06:38:21 -0400 In-Reply-To: <1311243679-18403-1-git-send-email-avi@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-07-21 12:21, Avi Kivity wrote: > Allow changes to the memory hierarchy to be accumulated and > made visible all at once. This reduces computational effort, > especially when an accelerator (e.g. kvm) is involved. > > Useful when a single register update causes multiple changes > to an address space. That's simple to implement in the core, but complicates life for the users, at least for the simple "update this region" use case. Do we have transactional scenarios during runtime where multiple memory regions are reconfigured? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux