From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzDkF-0003Wb-DE for qemu-devel@nongnu.org; Wed, 29 Apr 2009 13:38:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzDkB-0003Vc-JO for qemu-devel@nongnu.org; Wed, 29 Apr 2009 13:38:55 -0400 Received: from [199.232.76.173] (port=50210 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzDkB-0003VX-DZ for qemu-devel@nongnu.org; Wed, 29 Apr 2009 13:38:51 -0400 Received: from rv-out-0708.google.com ([209.85.198.249]:28210) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzDkB-0001Pa-28 for qemu-devel@nongnu.org; Wed, 29 Apr 2009 13:38:51 -0400 Received: by rv-out-0708.google.com with SMTP id c5so824853rvf.22 for ; Wed, 29 Apr 2009 10:38:49 -0700 (PDT) Message-ID: <49F890A5.8000405@codemonkey.ws> Date: Wed, 29 Apr 2009 12:38:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4/7] kvm: Add sanity checks to slot management References: <20090411172025.32383.77687.stgit@mchn012c.ww002.siemens.net> <20090411172026.32383.7492.stgit@mchn012c.ww002.siemens.net> <0A1FE637C2C7E148B9573BB60CC630E5210713@zch01exm26.fsl.freescale.net> <49F82E09.3070702@siemens.com> <1241025000.24990.51.camel@slate.austin.ibm.com> In-Reply-To: <1241025000.24990.51.camel@slate.austin.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: Jan Kiszka , Liu Yu-B13201 , qemu-devel@nongnu.org, kvm-ppc@vger.kernel.org Hollis Blanchard wrote: > On Wed, 2009-04-29 at 12:38 +0200, Jan Kiszka wrote: > >> What is the alignment of those regions then? None? And do regions of >> different types overlap even on the same page? Maybe the check reveals >> some deeper conflict /wrt KVM. Can you point me to the involved code files? >> > > These PCI controllers make separate calls to > cpu_register_physical_memory() for separate callbacks. Reading > ppce500_pci_init(), for example: > 0xe0008000 -> CFGADDR (4 bytes) > 0xe0008004 -> CFGDATA (4 bytes) > 0xe0008c00 -> other registers > That's goofy. If the single device owns the entire region, it should region the entire region instead of relying on subpage functionality. If just requires a switch() on the address to dispatch to the appropriate functions. It should be easy enough to fix. Regards, Anthony Liguori