From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LEo8f-0007xW-9J for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:00:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LEo8e-0007ws-23 for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:00:16 -0500 Received: from [199.232.76.173] (port=50514 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEo8d-0007wg-6e for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:00:15 -0500 Received: from qw-out-1920.google.com ([74.125.92.150]:41091) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LEo8c-0001uD-Mg for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:00:14 -0500 Received: by qw-out-1920.google.com with SMTP id 5so926838qwc.4 for ; Mon, 22 Dec 2008 09:00:13 -0800 (PST) Message-ID: <5d6222a80812220900x1d5e6301x7a6686ec56d25c61@mail.gmail.com> Date: Mon, 22 Dec 2008 15:00:12 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] [PATCH 5/6] hook cpu_register_physical_mem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1229619702-26315-1-git-send-email-glommer@redhat.com> <1229619702-26315-2-git-send-email-glommer@redhat.com> <1229619702-26315-3-git-send-email-glommer@redhat.com> <1229619702-26315-4-git-send-email-glommer@redhat.com> <1229619702-26315-5-git-send-email-glommer@redhat.com> <1229619702-26315-6-git-send-email-glommer@redhat.com> <494C096D.1050902@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: avi@redhat.com, Ian.Jackson@eu.citrix.com, kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com >> It really does though. The way physical memory is registered and managed >> is TCG specific right now. It has deep hooks for invalidating >> TranslationBlock's, and the table structure is designed to be conducive to >> the access patterns of TCG. > > Yes, but also dyngen stuff used the same structures, so it's a bit > more generic than TCG-only. yeah, but dyngen is gone now. So tcg really stands for "whatever qemu does", in here. > >> If you think of a higher level CPU API, I think registering physical memory >> and reading/writing physical memory would end up being part of that API. > > Thanks, I was looking for something like this. CPU emulator is more > than just TCG or dyngen and it is also ~KVM. So how about > cpu_emu_register_physical_memory_offset? > > Also noaccel_register_physical_memory_offset would fit. After this revision, I must say I'm less happy with the name "accel". It's really a cpu model. I'm even thinking about changing the name of it to QEMUCPUModel or whatever. (suggestions welcome) So "default" or "qemu" would be good choices IMHO. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."