From patchwork Tue Mar 5 17:21:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 159699 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp5222267jad; Tue, 5 Mar 2019 09:26:05 -0800 (PST) X-Google-Smtp-Source: APXvYqxNYnv8BtBPBsikFRlednO15poo15yQWDzXjU19gZmQjgx4JPEFcrOXSWb7QYKNyuE+4dw7 X-Received: by 2002:a25:44d:: with SMTP id 74mr3131884ybe.222.1551806765724; Tue, 05 Mar 2019 09:26:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551806765; cv=none; d=google.com; s=arc-20160816; b=RNYvjAhRtiuPvxjtczGOJUQtF7l2uU+r29kYM/KWxzggiggwcOPzCUX6amjuIfoZUE YGCUBns8LScyioolJbnh8b9IwtO5PPw+BQ0RNXUgMXvm1iZSsGfOB6+eIfrHjjLhw38j NTl6y1tiY/yMlgDWJmTGpPV7DK9BAFDQPGhxNNV/QieJ5TlYFkAdJN6ZthkyRkXEEYuN QsRu/TzfqlAsFAg2a4YbqCAe/aH+uLgEcozXx9ZUxQhkqpfhOsE+7d0w/wYtHKyC5JXp UFGHPqwJHt/beufFGIEPVYqsW8nYV3lcu+CuAUNObc/3wOpuD1QyVSJy330ffPuh++4N 8Svw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:to:from:dkim-signature; bh=wpBH3UVWa5xs78E58hfC7XY52d6PFrvdK5V9hk6kivY=; b=VHViMIUxTLteul2/PyZuFA1JW460FUQPzVQoanK9YfuRuE7baVZbSNX/syBFc/hYk1 EgcCS21brq0ZUQUviMuaSqldmw9yTKIBecC/i/0v1/yY2Ll5fFajQFjRbYnwUaR+0oFv St3e5V9ZsAUqnFDl4xLb2iA6ce2dAPmFCWFUMpyjqtKHAPEC40QXL3GNZIiptsCaib3N G9MypeDMbdyu9//w6WoNUDVtjn5P+kQ14JIdimDk2jw1iTgzVcYqnC3vfzlJUWP6MIaV VrlIlEzBCP4zn9dyEwPrYt3GoR3EjUmDKMxefRxPMkHZa/A4acnmfQ8n7bd13AYqtEHp t55A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linaro.org header.s=google header.b=SP86LY0V; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id v185si5407921ywv.45.2019.03.05.09.26.05 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 05 Mar 2019 09:26:05 -0800 (PST) Received-SPF: pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; dkim=fail header.i=@linaro.org header.s=google header.b=SP86LY0V; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1]:46510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1DpN-0005Wb-6b for patch@linaro.org; Tue, 05 Mar 2019 12:26:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1DlE-00028S-II for qemu-devel@nongnu.org; Tue, 05 Mar 2019 12:21:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1DlD-0000Yi-1L for qemu-devel@nongnu.org; Tue, 05 Mar 2019 12:21:48 -0500 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:47090) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h1DlC-0000U0-MF for qemu-devel@nongnu.org; Tue, 05 Mar 2019 12:21:46 -0500 Received: by mail-wr1-x443.google.com with SMTP id i16so10341457wrs.13 for ; Tue, 05 Mar 2019 09:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wpBH3UVWa5xs78E58hfC7XY52d6PFrvdK5V9hk6kivY=; b=SP86LY0V5SFSgnfL45AyAhp2C0qFhvV3fiJ2Wz983C0Q4Xwqi4xm++mGF4soebarEa ypAcCCRxKNWwFleVs28DFJ/4b4BE5eCMIG88ww4W8KZtZG8CgJouJepXkktemIU5C2Zg 6lz/SFD+dC7gzVJMzs9VmnJTHGTOSsO/dnH89l5n++G8RIdMklI8pmEhdGTK4uJqdOLF gjZNk+nXtoxa4+Nsn1oDQcsf/28bdUrVhfPSk/jds2sv0Zhn80+aTcCIhPxiaw9m99dJ ZU2eAWPU9CQWzNT4fqN5FU9BWFihVdtqptlok2BhSAaczTsWxQaH9GJECjKOzlUb+7B+ ltOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wpBH3UVWa5xs78E58hfC7XY52d6PFrvdK5V9hk6kivY=; b=iO4yNyIctSj4SxI2sxOTi1r96/YmbHEl6KxLkKOe8Ni8/BUFOo1A3e3J1qZ4YcfpfW RWdw9vgOP13Y8Nm+EOcHBnSzH2/hdjx+kEJ6ZM4gWmmv4KU+XGaVzn6pmnd66t2+Q3TC iH60cEZaRJQVNZRtoeUweeNHdDQXlM1uExA6AK+iJMe4SAH4jaQBLAlDhA1nB2G4UNhV IObtluudjN+i2/pPzqmySIBwnWFgKAeLTwhKOIKdbS18ANhelIwmQxKbRyEZNxzT9Syk SakbLALzOvh3FTwM/h65fgsSDY2WDDKr1SJp1llRIPAA9YZh0qeXZyuTjkrEYa6CNMrd qfIA== X-Gm-Message-State: APjAAAWB12qu0szr2ewYVM9ytYxdGgEwml9ThbfJRAzXGPylRtAvvpn+ D1pRAbSRWcfxYmkOPXbwVK3QwHo4YRE= X-Received: by 2002:a05:6000:1084:: with SMTP id y4mr2292wrw.14.1551806504775; Tue, 05 Mar 2019 09:21:44 -0800 (PST) Received: from orth.archaic.org.uk (orth.archaic.org.uk. [81.2.115.148]) by smtp.gmail.com with ESMTPSA id b195sm48289wmg.36.2019.03.05.09.21.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 09:21:44 -0800 (PST) From: Peter Maydell To: qemu-devel@nongnu.org Date: Tue, 5 Mar 2019 17:21:29 +0000 Message-Id: <20190305172139.32662-3-peter.maydell@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190305172139.32662-1-peter.maydell@linaro.org> References: <20190305172139.32662-1-peter.maydell@linaro.org> MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::443 Subject: [Qemu-devel] [PATCH v3 02/12] docs: Convert memory.txt to rst format X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?q?Alex_Benn=C3=A9e?= , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Aleksandar Markovic Errors-To: qemu-devel-bounces+patch=linaro.org@nongnu.org Sender: "Qemu-devel" Convert the memory API documentation from plain text to restructured text format. This is a very minimal conversion: all I had to change was to mark up the ASCII art parts as Sphinx expects for 'literal blocks', and fix up the bulleted lists (Sphinx expects no leading space before the bullet, and wants a blank line before after any list). Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Acked-by: Aleksandar Markovic Message-id: 20190228145624.24885-3-peter.maydell@linaro.org --- docs/devel/{memory.txt => memory.rst} | 128 ++++++++++++++------------ 1 file changed, 70 insertions(+), 58 deletions(-) rename docs/devel/{memory.txt => memory.rst} (85%) -- 2.20.1 Reviewed-by: Richard Henderson Reviewed-by: Cleber Rosa diff --git a/docs/devel/memory.txt b/docs/devel/memory.rst similarity index 85% rename from docs/devel/memory.txt rename to docs/devel/memory.rst index 42577e1d860..b6a4c37ea5e 100644 --- a/docs/devel/memory.txt +++ b/docs/devel/memory.rst @@ -1,19 +1,20 @@ +============== The memory API ============== The memory API models the memory and I/O buses and controllers of a QEMU machine. It attempts to allow modelling of: - - ordinary RAM - - memory-mapped I/O (MMIO) - - memory controllers that can dynamically reroute physical memory regions - to different destinations +- ordinary RAM +- memory-mapped I/O (MMIO) +- memory controllers that can dynamically reroute physical memory regions + to different destinations The memory model provides support for - - tracking RAM changes by the guest - - setting up coalesced memory for kvm - - setting up ioeventfd regions for kvm +- tracking RAM changes by the guest +- setting up coalesced memory for kvm +- setting up ioeventfd regions for kvm Memory is modelled as an acyclic graph of MemoryRegion objects. Sinks (leaves) are RAM and MMIO regions, while other nodes represent @@ -98,25 +99,30 @@ ROM device memory region types), this host memory needs to be copied to the destination on migration. These APIs which allocate the host memory for you will also register the memory so it is migrated: - - memory_region_init_ram() - - memory_region_init_rom() - - memory_region_init_rom_device() + +- memory_region_init_ram() +- memory_region_init_rom() +- memory_region_init_rom_device() For most devices and boards this is the correct thing. If you have a special case where you need to manage the migration of the backing memory yourself, you can call the functions: - - memory_region_init_ram_nomigrate() - - memory_region_init_rom_nomigrate() - - memory_region_init_rom_device_nomigrate() + +- memory_region_init_ram_nomigrate() +- memory_region_init_rom_nomigrate() +- memory_region_init_rom_device_nomigrate() + which only initialize the MemoryRegion and leave handling migration to the caller. The functions: - - memory_region_init_resizeable_ram() - - memory_region_init_ram_from_file() - - memory_region_init_ram_from_fd() - - memory_region_init_ram_ptr() - - memory_region_init_ram_device_ptr() + +- memory_region_init_resizeable_ram() +- memory_region_init_ram_from_file() +- memory_region_init_ram_from_fd() +- memory_region_init_ram_ptr() +- memory_region_init_ram_device_ptr() + are for special cases only, and so they do not automatically register the backing memory for migration; the caller must manage migration if necessary. @@ -218,7 +224,7 @@ For example, suppose we have a container A of size 0x8000 with two subregions B and C. B is a container mapped at 0x2000, size 0x4000, priority 2; C is an MMIO region mapped at 0x0, size 0x6000, priority 1. B currently has two of its own subregions: D of size 0x1000 at offset 0 and E of size 0x1000 at -offset 0x2000. As a diagram: +offset 0x2000. As a diagram:: 0 1000 2000 3000 4000 5000 6000 7000 8000 |------|------|------|------|------|------|------|------| @@ -228,8 +234,9 @@ offset 0x2000. As a diagram: D: [DDDDD] E: [EEEEE] -The regions that will be seen within this address range then are: - [CCCCCCCCCCCC][DDDDD][CCCCC][EEEEE][CCCCC] +The regions that will be seen within this address range then are:: + + [CCCCCCCCCCCC][DDDDD][CCCCC][EEEEE][CCCCC] Since B has higher priority than C, its subregions appear in the flat map even where they overlap with C. In ranges where B has not mapped anything @@ -237,8 +244,9 @@ C's region appears. If B had provided its own MMIO operations (ie it was not a pure container) then these would be used for any addresses in its range not handled by -D or E, and the result would be: - [CCCCCCCCCCCC][DDDDD][BBBBB][EEEEE][BBBBB] +D or E, and the result would be:: + + [CCCCCCCCCCCC][DDDDD][BBBBB][EEEEE][BBBBB] Priority values are local to a container, because the priorities of two regions are only compared when they are both children of the same container. @@ -257,6 +265,7 @@ guest accesses an address: - all direct subregions of the root region are matched against the address, in descending priority order + - if the address lies outside the region offset/size, the subregion is discarded - if the subregion is a leaf (RAM or MMIO), the search terminates, returning @@ -270,36 +279,39 @@ guest accesses an address: address range), then if this is a container with its own MMIO or RAM backing the search terminates, returning the container itself. Otherwise we continue with the next subregion in priority order + - if none of the subregions match the address then the search terminates with no match found Example memory map ------------------ -system_memory: container@0-2^48-1 - | - +---- lomem: alias@0-0xdfffffff ---> #ram (0-0xdfffffff) - | - +---- himem: alias@0x100000000-0x11fffffff ---> #ram (0xe0000000-0xffffffff) - | - +---- vga-window: alias@0xa0000-0xbffff ---> #pci (0xa0000-0xbffff) - | (prio 1) - | - +---- pci-hole: alias@0xe0000000-0xffffffff ---> #pci (0xe0000000-0xffffffff) +:: -pci (0-2^32-1) - | - +--- vga-area: container@0xa0000-0xbffff - | | - | +--- alias@0x00000-0x7fff ---> #vram (0x010000-0x017fff) - | | - | +--- alias@0x08000-0xffff ---> #vram (0x020000-0x027fff) - | - +---- vram: ram@0xe1000000-0xe1ffffff - | - +---- vga-mmio: mmio@0xe2000000-0xe200ffff + system_memory: container@0-2^48-1 + | + +---- lomem: alias@0-0xdfffffff ---> #ram (0-0xdfffffff) + | + +---- himem: alias@0x100000000-0x11fffffff ---> #ram (0xe0000000-0xffffffff) + | + +---- vga-window: alias@0xa0000-0xbffff ---> #pci (0xa0000-0xbffff) + | (prio 1) + | + +---- pci-hole: alias@0xe0000000-0xffffffff ---> #pci (0xe0000000-0xffffffff) -ram: ram@0x00000000-0xffffffff + pci (0-2^32-1) + | + +--- vga-area: container@0xa0000-0xbffff + | | + | +--- alias@0x00000-0x7fff ---> #vram (0x010000-0x017fff) + | | + | +--- alias@0x08000-0xffff ---> #vram (0x020000-0x027fff) + | + +---- vram: ram@0xe1000000-0xe1ffffff + | + +---- vga-mmio: mmio@0xe2000000-0xe200ffff + + ram: ram@0x00000000-0xffffffff This is a (simplified) PC memory map. The 4GB RAM block is mapped into the system address space via two aliases: "lomem" is a 1:1 mapping of the first @@ -336,16 +348,16 @@ rather than completing successfully; those devices can use the In addition various constraints can be supplied to control how these callbacks are called: - - .valid.min_access_size, .valid.max_access_size define the access sizes - (in bytes) which the device accepts; accesses outside this range will - have device and bus specific behaviour (ignored, or machine check) - - .valid.unaligned specifies that the *device being modelled* supports - unaligned accesses; if false, unaligned accesses will invoke the - appropriate bus or CPU specific behaviour. - - .impl.min_access_size, .impl.max_access_size define the access sizes - (in bytes) supported by the *implementation*; other access sizes will be - emulated using the ones available. For example a 4-byte write will be - emulated using four 1-byte writes, if .impl.max_access_size = 1. - - .impl.unaligned specifies that the *implementation* supports unaligned - accesses; if false, unaligned accesses will be emulated by two aligned - accesses. +- .valid.min_access_size, .valid.max_access_size define the access sizes + (in bytes) which the device accepts; accesses outside this range will + have device and bus specific behaviour (ignored, or machine check) +- .valid.unaligned specifies that the *device being modelled* supports + unaligned accesses; if false, unaligned accesses will invoke the + appropriate bus or CPU specific behaviour. +- .impl.min_access_size, .impl.max_access_size define the access sizes + (in bytes) supported by the *implementation*; other access sizes will be + emulated using the ones available. For example a 4-byte write will be + emulated using four 1-byte writes, if .impl.max_access_size = 1. +- .impl.unaligned specifies that the *implementation* supports unaligned + accesses; if false, unaligned accesses will be emulated by two aligned + accesses.