From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH 7/9] register mmio slots Date: Mon, 22 Sep 2008 10:55:30 -0300 Message-ID: <20080922135530.GE3618@poweredge.glommer> References: <1221840506-22996-1-git-send-email-glommer@redhat.com> <1221840506-22996-8-git-send-email-glommer@redhat.com> <48D5431E.9090102@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, aliguori@us.ibm.com To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:54249 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752189AbYIVNy6 (ORCPT ); Mon, 22 Sep 2008 09:54:58 -0400 Content-Disposition: inline In-Reply-To: <48D5431E.9090102@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sat, Sep 20, 2008 at 11:38:22AM -0700, Avi Kivity wrote: > Glauber Costa wrote: >> By analysing phys_offset, we know whether a region is an mmio region >> or not. If it is, register it as so. We don't reuse the same slot >> infrastructure already existant, because there is a relationship between >> the slot number for kvm the kernel module, and the index in the slots vector >> for libkvm. However, we can do best in the future and use only a single data structure >> for both. >> >> > > Why is kvm interested in emulated mmio regions, at all? We don't need to. If the region is an mmio region, we do nothing (well, later on, I'm coalescing the accesses). But still, we need to keep track. Otherwise, qemu can (and it will) try to register subsets of that memory, but without any indication that this is part of an mmio region Our algorithm will fail in this case, since we will then register a memory area we should have left blank. So think of mmio in this case as a "please leave it blank". > > >> @@ -1032,11 +1042,9 @@ void kvm_mutex_lock(void) >> int qemu_kvm_register_coalesced_mmio(target_phys_addr_t addr, >> unsigned int size) >> { >> - return kvm_register_coalesced_mmio(kvm_context, addr, size); >> } >> int qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr, >> unsigned int size) >> { >> - return kvm_unregister_coalesced_mmio(kvm_context, addr, size); >> } >> > > Why? Because I'm doing automatic mmio coalescing in memory registration. It's the way I saw to remove all the calls spread through the code, for merging purposes. Any better idea? > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. >