From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/9] Don't separate registrations with IO_MEM_ROM set Date: Fri, 12 Sep 2008 17:47:40 +0200 Message-ID: <48CA8F1C.1040104@siemens.com> References: <1221232250-9653-1-git-send-email-glommer@redhat.com> <1221232250-9653-2-git-send-email-glommer@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, jes@sgi.com, avi@qumranet.com, aliguori@us.ibm.com To: Glauber Costa Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:16701 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753762AbYILPsX (ORCPT ); Fri, 12 Sep 2008 11:48:23 -0400 In-Reply-To: <1221232250-9653-2-git-send-email-glommer@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Glauber Costa wrote: > Actually, all registrations are the same. If IO_MEM_ROM is set, we only > need to take care of not passing its value as the phys_offset. As you are turning things upside down already: :-> Any idea how to deal with that "real-only" property of IO_MEM_ROM? And how to handle memory remappings during runtime (like i440fx_update_memory_mappings does)? I like the hook-approach for kvm_cpu_register_physical_memory a lot. But note that - at least so far - cpu_register_physical_memory is sometimes misused to change the protection or the origin of some memory region. That should be taken into account. Or the qemu interface should be refactored first so that kvm (or qemuaccel) can cleanly hook into dedicated remapping/protection changing services. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux