From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFhB7-0003SL-7s for qemu-devel@nongnu.org; Thu, 05 Apr 2012 03:32:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFhB5-0006tB-H8 for qemu-devel@nongnu.org; Thu, 05 Apr 2012 03:32:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]:17159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFhB5-0006t3-6u for qemu-devel@nongnu.org; Thu, 05 Apr 2012 03:32:19 -0400 Message-ID: <4F7D4A7D.9030206@siemens.com> Date: Thu, 05 Apr 2012 09:32:13 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1333339457-13854-1-git-send-email-david@gibson.dropbear.id.au> <4F7AA1E0.2070201@web.de> <20120404011238.GC17423@truffala.fritz.box> <4F7C295D.8090202@siemens.com> <20120404142458.GB19379@truffala.fritz.box> In-Reply-To: <20120404142458.GB19379@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mtosatti@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Avi Kivity On 2012-04-04 16:24, David Gibson wrote: > On Wed, Apr 04, 2012 at 12:58:37PM +0200, Jan Kiszka wrote: >> On 2012-04-04 03:12, David Gibson wrote: >>>> Also, what's about coalesced MMIO? I see that the ring definition >>>> depends on [TARGET_]PAGE_SIZE. What page size does the power kernel use >>>> for it, and does it make a relevant difference for space? >>> >>> Hr, so the HV variant of Power KVM doesn't do coalesced mmio. The PR >>> variant does, but I don't know enough about it to easily answer that. >>> If there's a bug there, it hasn't bitten yet, so how about we fix that >>> another day. >> >> Not really a smart approach, specifically now that we are aware of a >> potential problem here. > > My point is that the fact that there may be another bug out there > should sure as hell not hold up putting this bug fix in. The bugs may > have similar causes and solutions, but they're entirely different code > paths and the other fix will in no way replace or subsume this one. I don't disagree. Maybe I over-interpreted your reply as "let's wait if this actually bites us". Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux