From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFptA-0005D4-Ar for qemu-devel@nongnu.org; Fri, 29 Apr 2011 11:45:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFpt9-00028V-8q for qemu-devel@nongnu.org; Fri, 29 Apr 2011 11:45:52 -0400 Received: from david.siemens.de ([192.35.17.14]:20715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFpt8-00028B-Q2 for qemu-devel@nongnu.org; Fri, 29 Apr 2011 11:45:51 -0400 Message-ID: <4DBADD2B.2050300@siemens.com> Date: Fri, 29 Apr 2011 17:45:47 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20110429031437.3796.49456.stgit@s20.home> <20110429150640.GB27816@redhat.com> <4DBAD942.6080001@siemens.com> <1304091508.3418.11.camel@x201> In-Reply-To: <1304091508.3418.11.camel@x201> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Fix phys memory client - pass guest physical address not region offset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: "qemu-devel@nongnu.org" , "Michael S. Tsirkin" On 2011-04-29 17:38, Alex Williamson wrote: > On Fri, 2011-04-29 at 17:29 +0200, Jan Kiszka wrote: >> On 2011-04-29 17:06, Michael S. Tsirkin wrote: >>> On Thu, Apr 28, 2011 at 09:15:23PM -0600, Alex Williamson wrote: >>>> When we're trying to get a newly registered phys memory client updated >>>> with the current page mappings, we end up passing the region offset >>>> (a ram_addr_t) as the start address rather than the actual guest >>>> physical memory address (target_phys_addr_t). If your guest has less >>>> than 3.5G of memory, these are coincidentally the same thing. If >> >> I think this broke even with < 3.5G as phys_offset also encodes the >> memory type while region_offset does not. So everything became RAMthis >> way, no MMIO was announced. >> >>>> there's more, the region offset for the memory above 4G starts over >>>> at 0, so the set_memory client will overwrite it's lower memory entries. >>>> >>>> Instead, keep track of the guest phsyical address as we're walking the >>>> tables and pass that to the set_memory client. >>>> >>>> Signed-off-by: Alex Williamson >>> >>> Acked-by: Michael S. Tsirkin >>> >>> Given all this, can yo tell how much time does >>> it take to hotplug a device with, say, a 40G RAM guest? >> >> Why not collect pages of identical types and report them as one chunk >> once the type changes? > > Good idea, I'll see if I can code that up. I don't have a terribly > large system to test with, but with an 8G guest, it's surprisingly not > very noticeable. For vfio, I intend to only have one memory client, so > adding additional devices won't have to rescan everything. The memory > overhead of keeping the list that the memory client creates is probably > also low enough that it isn't worthwhile to tear it all down if all the > devices are removed. Thanks, What other clients register late? Do the need to know to whole memory layout? This full page table walk is likely a latency killer as it happens under global lock. Ugly. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux