From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHTax-0004bl-E7 for qemu-devel@nongnu.org; Fri, 08 Jan 2016 04:44:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHTau-0000h5-4i for qemu-devel@nongnu.org; Fri, 08 Jan 2016 04:44:31 -0500 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:37697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHTat-0000h1-UY for qemu-devel@nongnu.org; Fri, 08 Jan 2016 04:44:28 -0500 Received: by mail-wm0-x22c.google.com with SMTP id f206so162631610wmf.0 for ; Fri, 08 Jan 2016 01:44:27 -0800 (PST) Sender: Paolo Bonzini References: From: Paolo Bonzini Message-ID: <568F84F9.1050109@redhat.com> Date: Fri, 8 Jan 2016 10:44:25 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How guest physical RAM works List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , qemu-devel Cc: Igor Mammedov , Luiz Capitulino On 08/01/2016 10:29, Stefan Hajnoczi wrote: > As a side-note, the initial RAM that the guest started with might not > be modelled with a "pc-dimm" device and it can't be unplugged. > > The guest RAM itself isn't contained inside the "pc-dimm" object. > Instead the "pc-dimm" must be associated with a "memory-backend" > object. Perhaps it's worth mentioning that the initial RAM can also be associated with one or more memory-backend objects, typically one per virtual NUMA node. The memory-backend is passed to QEMU via "-numa node,...,memdev=ID". > The MemoryRegion is the link between guest physical address space and > the RAMBlocks containing the memory. Each MemoryRegion has the > ram_addr_t offset of the RAMBlock and each RAMBlock has a MemoryRegion > pointer. As a side note (probably beyond the scope of your post) there is no reason for the MemoryRegion to use the ram_addr_t instead of the RAMBlock. It would actually be faster if the MemoryRegion contained the RAMBlock, since it's slow to look up the mmap address corresponding to the ram_addr_t. There is a 1-element MRU cache, but it's still slowish. Paolo