[{"id":3190630,"web_url":"http://patchwork.ozlabs.org/comment/3190630/","msgid":"<11c6efbd-b794-4a05-9c51-4928fb545db4@maciej.szmigiero.name>","list_archive_url":null,"date":"2023-09-30T17:31:40","subject":"Re: [PATCH v4 16/18] virtio-mem: Expose device memory dynamically via\n multiple memslots if enabled","submitter":{"id":65914,"url":"http://patchwork.ozlabs.org/api/people/65914/","name":"Maciej S. Szmigiero","email":"mail@maciej.szmigiero.name"},"content":"On 26.09.2023 20:57, David Hildenbrand wrote:\n> Having large virtio-mem devices that only expose little memory to a VM\n> is currently a problem: we map the whole sparse memory region into the\n> guest using a single memslot, resulting in one gigantic memslot in KVM.\n> KVM allocates metadata for the whole memslot, which can result in quite\n> some memory waste.\n> \n> Assuming we have a 1 TiB virtio-mem device and only expose little (e.g.,\n> 1 GiB) memory, we would create a single 1 TiB memslot and KVM has to\n> allocate metadata for that 1 TiB memslot: on x86, this implies allocating\n> a significant amount of memory for metadata:\n> \n> (1) RMAP: 8 bytes per 4 KiB, 8 bytes per 2 MiB, 8 bytes per 1 GiB\n> -> For 1 TiB: 2147483648 + 4194304 + 8192 = ~ 2 GiB (0.2 %)\n> \n> With the TDP MMU (cat /sys/module/kvm/parameters/tdp_mmu) this gets\n> allocated lazily when required for nested VMs\n> (2) gfn_track: 2 bytes per 4 KiB\n> -> For 1 TiB: 536870912 = ~512 MiB (0.05 %)\n> (3) lpage_info: 4 bytes per 2 MiB, 4 bytes per 1 GiB\n> -> For 1 TiB: 2097152 + 4096 = ~2 MiB (0.0002 %)\n> (4) 2x dirty bitmaps for tracking: 2x 1 bit per 4 KiB page\n> -> For 1 TiB: 536870912 = 64 MiB (0.006 %)\n> \n> So we primarily care about (1) and (2). The bad thing is, that the\n> memory consumption *doubles* once SMM is enabled, because we create the\n> memslot once for !SMM and once for SMM.\n> \n> Having a 1 TiB memslot without the TDP MMU consumes around:\n> * With SMM: 5 GiB\n> * Without SMM: 2.5 GiB\n> Having a 1 TiB memslot with the TDP MMU consumes around:\n> * With SMM: 1 GiB\n> * Without SMM: 512 MiB\n> \n> ... and that's really something we want to optimize, to be able to just\n> start a VM with small boot memory (e.g., 4 GiB) and a virtio-mem device\n> that can grow very large (e.g., 1 TiB).\n> \n> Consequently, using multiple memslots and only mapping the memslots we\n> really need can significantly reduce memory waste and speed up\n> memslot-related operations. Let's expose the sparse RAM memory region using\n> multiple memslots, mapping only the memslots we currently need into our\n> device memory region container.\n> \n> The feature can be enabled using \"dynamic-memslots=on\" and requires\n> \"unplugged-inaccessible=on\", which is nowadays the default.\n> \n> Once enabled, we'll auto-detect the number of memslots to use based on the\n> memslot limit provided by the core. We'll use at most 1 memslot per\n> gigabyte. Note that our global limit of memslots accross all memory devices\n> is currently set to 256: even with multiple large virtio-mem devices,\n> we'd still have a sane limit on the number of memslots used.\n> \n> The default is to not dynamically map memslot for now\n> (\"dynamic-memslots=off\"). The optimization must be enabled manually,\n> because some vhost setups (e.g., hotplug of vhost-user devices) might be\n> problematic until we support more memslots especially in vhost-user backends.\n> \n> Note that \"dynamic-memslots=on\" is just a hint that multiple memslots\n> *may* be used for internal optimizations, not that multiple memslots\n> *must* be used. The actual number of memslots that are used is an\n> internal detail: for example, once memslot metadata is no longer an\n> issue, we could simply stop optimizing for that. Migration source and\n> destination can differ on the setting of \"dynamic-memslots\".\n> \n> Signed-off-by: David Hildenbrand \n> ---\n\nThe changes seem reasonable, so:\nReviewed-by: Maciej S. Szmigiero \n\nThanks,\nMaciej","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RyZ710Nq3z1yp7\n\tfor ; Sun, 1 Oct 2023 04:32:59 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmdp1-00081z-I5; Sat, 30 Sep 2023 13:32:07 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmdox-000809-Od\n for qemu-devel@nongnu.org; Sat, 30 Sep 2023 13:32:03 -0400","from vps-vb.mhejs.net ([37.28.154.113])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmdov-0000T2-Kk\n for qemu-devel@nongnu.org; Sat, 30 Sep 2023 13:32:03 -0400","from MUA by vps-vb.mhejs.net with esmtps (TLS1.2) tls\n TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2)\n (envelope-from )\n id 1qmdog-0008Pz-Nr; Sat, 30 Sep 2023 19:31:46 +0200"],"Message-ID":"<11c6efbd-b794-4a05-9c51-4928fb545db4@maciej.szmigiero.name>","Date":"Sat, 30 Sep 2023 19:31:40 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4 16/18] virtio-mem: Expose device memory dynamically via\n multiple memslots if enabled","Content-Language":"en-US, pl-PL","To":"David Hildenbrand ","Cc":"Paolo Bonzini , Igor Mammedov ,\n Xiao Guangrong ,\n \"Michael S. Tsirkin\" , Peter Xu ,\n\t=?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,\n Eduardo Habkost ,\n Marcel Apfelbaum ,\n Yanan Wang , Michal Privoznik ,\n\t=?utf-8?q?Daniel_P_=2E_Berrang=C3=A9?= ,\n Gavin Shan , Alex Williamson ,\n Stefan Hajnoczi , kvm@vger.kernel.org,\n qemu-devel@nongnu.org","References":"<20230926185738.277351-1-david@redhat.com>\n <20230926185738.277351-17-david@redhat.com>","From":"\"Maciej S. Szmigiero\" ","Autocrypt":"addr=mail@maciej.szmigiero.name; keydata=\n xsFNBFpGusUBEADXUMM2t7y9sHhI79+2QUnDdpauIBjZDukPZArwD+sDlx5P+jxaZ13XjUQc\n 6oJdk+jpvKiyzlbKqlDtw/Y2Ob24tg1g/zvkHn8AVUwX+ZWWewSZ0vcwp7u/LvA+w2nJbIL1\n N0/QUUdmxfkWTHhNqgkNX5hEmYqhwUPozFR0zblfD/6+XFR7VM9yT0fZPLqYLNOmGfqAXlxY\n m8nWmi+lxkd/PYqQQwOq6GQwxjRFEvSc09m/YPYo9hxh7a6s8hAP88YOf2PD8oBB1r5E7KGb\n Fv10Qss4CU/3zaiyRTExWwOJnTQdzSbtnM3S8/ZO/sL0FY/b4VLtlZzERAraxHdnPn8GgxYk\n oPtAqoyf52RkCabL9dsXPWYQjkwG8WEUPScHDy8Uoo6imQujshG23A99iPuXcWc/5ld9mIo/\n Ee7kN50MOXwS4vCJSv0cMkVhh77CmGUv5++E/rPcbXPLTPeRVy6SHgdDhIj7elmx2Lgo0cyh\n uyxyBKSuzPvb61nh5EKAGL7kPqflNw7LJkInzHqKHDNu57rVuCHEx4yxcKNB4pdE2SgyPxs9\n 9W7Cz0q2Hd7Yu8GOXvMfQfrBiEV4q4PzidUtV6sLqVq0RMK7LEi0RiZpthwxz0IUFwRw2KS/\n 9Kgs9LmOXYimodrV0pMxpVqcyTepmDSoWzyXNP2NL1+GuQtaTQARAQABzTBNYWNpZWogUy4g\n U3ptaWdpZXJvIDxtYWlsQG1hY2llai5zem1pZ2llcm8ubmFtZT7CwZQEEwEIAD4CGwMFCwkI\n BwIGFQoJCAsCBBYCAwECHgECF4AWIQRyeg1N257Z9gOb7O+Ef143kM4JdwUCZHu3rAUJC4vC\n 5wAKCRCEf143kM4Jdw74EAC6WUqhTI7MKKqJIjFpR3IxzqAKhoTl/lKPnhzwnB9Zdyj9WJlv\n wIITsQOvhHj6K2Ds63zmh/NKccMY8MDaBnffXnH8fi9kgBKHpPPMXJj1QOXCONlCVp5UGM8X\n j/gs94QmMxhr9TPY5WBa50sDW441q8zrDB8+B/hfbiE1B5k9Uwh6p/aAzEzLCb/rp9ELUz8/\n bax/e8ydtHpcbAMCRrMLkfID127dlLltOpOr+id+ACRz0jabaWqoGjCHLIjQEYGVxdSzzu+b\n 27kWIcUPWm+8hNX35U3ywT7cnU/UOHorEorZyad3FkoVYfz/5necODocsIiBn2SJ3zmqTdBe\n sqmYKDf8gzhRpRqc+RrkWJJ98ze2A9w/ulLBC5lExXCjIAdckt2dLyPtsofmhJbV/mIKcbWx\n GX4vw1ufUIJmkbVFlP2MAe978rdj+DBHLuWT0uusPgOqpgO9v12HuqYgyBDpZ2cvhjU+uPAj\n Bx8eLu/tpxEHGONpdET42esoaIlsNnHC7SehyOH/liwa6Ew0roRHp+VZUaf9yE8lS0gNlKzB\n H5YPyYBMVSRNokVG4QUkzp30nJDIZ6GdAUZ1bfafSHFHH1wzmOLrbNquyZRIAkcNCFuVtHoY\n CUDuGAnZlqV+e4BLBBtl9VpJOS6PHKx0k6A8D86vtCMaX/M/SSdbL6Kd5M7AzQRaRrwiAQwA\n xnVmJqeP9VUTISps+WbyYFYlMFfIurl7tzK74bc67KUBp+PHuDP9p4ZcJUGC3UZJP85/GlUV\n dE1NairYWEJQUB7bpogTuzMI825QXIB9z842HwWfP2RW5eDtJMeujzJeFaUpmeTG9snzaYxY\n N3r0TDKj5dZwSIThIMQpsmhH2zylkT0jH7kBPxb8IkCQ1c6wgKITwoHFjTIO0B75U7bBNSDp\n XUaUDvd6T3xd1Fz57ujAvKHrZfWtaNSGwLmUYQAcFvrKDGPB5Z3ggkiTtkmW3OCQbnIxGJJw\n /+HefYhB5/kCcpKUQ2RYcYgCZ0/WcES1xU5dnNe4i0a5gsOFSOYCpNCfTHttVxKxZZTQ/rxj\n XwTuToXmTI4Nehn96t25DHZ0t9L9UEJ0yxH2y8Av4rtf75K2yAXFZa8dHnQgCkyjA/gs0ujG\n wD+Gs7dYQxP4i+rLhwBWD3mawJxLxY0vGwkG7k7npqanlsWlATHpOdqBMUiAR22hs02FikAo\n iXNgWTy7ABEBAAHCwXwEGAEIACYCGwwWIQRyeg1N257Z9gOb7O+Ef143kM4JdwUCZHu3zQUJ\n C4vBowAKCRCEf143kM4Jd2NnD/9E9Seq0HDZag4Uazn9cVsYWV/cPK4vKSqeGWMeLpJlG/UB\n PHY9q8a79jukEArt610oWj7+wL8SG61/YOyvYaC+LT9R54K8juP66hLCUTNDmv8s9DEzJkDP\n +ct8MwzA3oYtuirzbas0qaSwxHjZ3aV40vZk0uiDDG6kK24pv3SXcMDWz8m+sKu3RI3H+hdQ\n gnDrBIfTeeT6DCEgTHsaotFDc7vaNESElHHldCZTrg56T82to6TMm571tMW7mbg9O+u2pUON\n xEQ5hHCyvNrMAEel191KTWKE0Uh4SFrLmYYCRL9RIgUzxFF+ahPxjtjhkBmtQC4vQ20Bc3X6\n 35ThI4munnjDmhM4eWVdcmDN4c8y+2FN/uHS5IUcfb9/7w+BWiELb3yGienDZ44U6j+ySA39\n gT6BAecNNIP47FG3AZXT3C1FZwFgkKoZ3lgN5VZgX2Gj53XiHqIGO8c3ayvHYAmrgtYYXG1q\n H5/qn1uUAhP1Oz+jKLUECbPS2ll73rFXUr+U3AKyLpx4T+/Wy1ajKn7rOB7udmTmYb8nnlQb\n 0fpPzYGBzK7zWIzFotuS5x1PzLYhZQFkfegyAaxys2joryhI6YNFo+BHYTfamOVfFi8QFQL5\n 5ZSOo27q/Ox95rwuC/n+PoJxBfqU36XBi886VV4LxuGZ8kfy0qDpL5neYtkC9w==","In-Reply-To":"<20230926185738.277351-17-david@redhat.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","Received-SPF":"pass client-ip=37.28.154.113;\n envelope-from=mail@maciej.szmigiero.name; helo=vps-vb.mhejs.net","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3191002,"web_url":"http://patchwork.ozlabs.org/comment/3191002/","msgid":"<56cec8a9-f4bb-5e9e-a1c4-223359f8b491@redhat.com>","list_archive_url":null,"date":"2023-10-02T08:57:40","subject":"Re: [PATCH v4 16/18] virtio-mem: Expose device memory dynamically via\n multiple memslots if enabled","submitter":{"id":70402,"url":"http://patchwork.ozlabs.org/api/people/70402/","name":"David Hildenbrand","email":"david@redhat.com"},"content":"On 30.09.23 19:31, Maciej S. Szmigiero wrote:\n> On 26.09.2023 20:57, David Hildenbrand wrote:\n>> Having large virtio-mem devices that only expose little memory to a VM\n>> is currently a problem: we map the whole sparse memory region into the\n>> guest using a single memslot, resulting in one gigantic memslot in KVM.\n>> KVM allocates metadata for the whole memslot, which can result in quite\n>> some memory waste.\n>>\n>> Assuming we have a 1 TiB virtio-mem device and only expose little (e.g.,\n>> 1 GiB) memory, we would create a single 1 TiB memslot and KVM has to\n>> allocate metadata for that 1 TiB memslot: on x86, this implies allocating\n>> a significant amount of memory for metadata:\n>>\n>> (1) RMAP: 8 bytes per 4 KiB, 8 bytes per 2 MiB, 8 bytes per 1 GiB\n>> -> For 1 TiB: 2147483648 + 4194304 + 8192 = ~ 2 GiB (0.2 %)\n>>\n>> With the TDP MMU (cat /sys/module/kvm/parameters/tdp_mmu) this gets\n>> allocated lazily when required for nested VMs\n>> (2) gfn_track: 2 bytes per 4 KiB\n>> -> For 1 TiB: 536870912 = ~512 MiB (0.05 %)\n>> (3) lpage_info: 4 bytes per 2 MiB, 4 bytes per 1 GiB\n>> -> For 1 TiB: 2097152 + 4096 = ~2 MiB (0.0002 %)\n>> (4) 2x dirty bitmaps for tracking: 2x 1 bit per 4 KiB page\n>> -> For 1 TiB: 536870912 = 64 MiB (0.006 %)\n>>\n>> So we primarily care about (1) and (2). The bad thing is, that the\n>> memory consumption *doubles* once SMM is enabled, because we create the\n>> memslot once for !SMM and once for SMM.\n>>\n>> Having a 1 TiB memslot without the TDP MMU consumes around:\n>> * With SMM: 5 GiB\n>> * Without SMM: 2.5 GiB\n>> Having a 1 TiB memslot with the TDP MMU consumes around:\n>> * With SMM: 1 GiB\n>> * Without SMM: 512 MiB\n>>\n>> ... and that's really something we want to optimize, to be able to just\n>> start a VM with small boot memory (e.g., 4 GiB) and a virtio-mem device\n>> that can grow very large (e.g., 1 TiB).\n>>\n>> Consequently, using multiple memslots and only mapping the memslots we\n>> really need can significantly reduce memory waste and speed up\n>> memslot-related operations. Let's expose the sparse RAM memory region using\n>> multiple memslots, mapping only the memslots we currently need into our\n>> device memory region container.\n>>\n>> The feature can be enabled using \"dynamic-memslots=on\" and requires\n>> \"unplugged-inaccessible=on\", which is nowadays the default.\n>>\n>> Once enabled, we'll auto-detect the number of memslots to use based on the\n>> memslot limit provided by the core. We'll use at most 1 memslot per\n>> gigabyte. Note that our global limit of memslots accross all memory devices\n>> is currently set to 256: even with multiple large virtio-mem devices,\n>> we'd still have a sane limit on the number of memslots used.\n>>\n>> The default is to not dynamically map memslot for now\n>> (\"dynamic-memslots=off\"). The optimization must be enabled manually,\n>> because some vhost setups (e.g., hotplug of vhost-user devices) might be\n>> problematic until we support more memslots especially in vhost-user backends.\n>>\n>> Note that \"dynamic-memslots=on\" is just a hint that multiple memslots\n>> *may* be used for internal optimizations, not that multiple memslots\n>> *must* be used. The actual number of memslots that are used is an\n>> internal detail: for example, once memslot metadata is no longer an\n>> issue, we could simply stop optimizing for that. Migration source and\n>> destination can differ on the setting of \"dynamic-memslots\".\n>>\n>> Signed-off-by: David Hildenbrand \n>> ---\n> \n> The changes seem reasonable, so:\n> Reviewed-by: Maciej S. Szmigiero \n\n\nThanks Maciej!","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=R3+nrtea;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RzZcW48LSz1ypx\n\tfor ; Mon, 2 Oct 2023 19:58:35 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qnEkc-0001Pp-Eb; Mon, 02 Oct 2023 04:58:02 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1qnEkO-0001Ok-Vz\n for qemu-devel@nongnu.org; Mon, 02 Oct 2023 04:57:49 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1qnEkN-0003PP-0E\n for qemu-devel@nongnu.org; Mon, 02 Oct 2023 04:57:48 -0400","from mail-wm1-f71.google.com (mail-wm1-f71.google.com\n [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-52-KQbGbYXXMMmqoDsGukY_kQ-1; Mon, 02 Oct 2023 04:57:43 -0400","by mail-wm1-f71.google.com with SMTP id\n 5b1f17b1804b1-3fd0fa4d08cso134062645e9.1\n for ; Mon, 02 Oct 2023 01:57:43 -0700 (PDT)","from ?IPV6:2003:cb:c735:f200:cb49:cb8f:88fc:9446?\n (p200300cbc735f200cb49cb8f88fc9446.dip0.t-ipconnect.de.\n [2003:cb:c735:f200:cb49:cb8f:88fc:9446])\n by smtp.gmail.com with ESMTPSA id\n n3-20020adff083000000b003143867d2ebsm27577613wro.63.2023.10.02.01.57.40\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Mon, 02 Oct 2023 01:57:41 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1696237065;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=fVukFMHb4sPlTBNho7wcg3FCMW675wzniIBiQO49dIQ=;\n b=R3+nrteagWKVrZW+oo0oFGizGg8mtojpGFIhsBuiaNX1SNYyzJYzuHtu/J1DRcv76TQ4Eb\n MRy0MJ/x3wfflQ0RHHxDN2bld7xSQ0ruilM9dHhZH1nx8Hx6EyrIBWTIjUaPy8tOsk7jDr\n A5ONtxxGKjDTqvMHOqN++LMiviSL25Y=","X-MC-Unique":"KQbGbYXXMMmqoDsGukY_kQ-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696237062; x=1696841862;\n h=content-transfer-encoding:in-reply-to:organization:from:references\n :cc:to:content-language:subject:user-agent:mime-version:date\n :message-id:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=fVukFMHb4sPlTBNho7wcg3FCMW675wzniIBiQO49dIQ=;\n b=bw9skY6tNc86H0lepDjIuPdJuJsE73hqE07lCL58Wm8JBZdocPmvAkXwkuZJTuNCvf\n zFv4dDOgIL+bJXw2ffzGDJKb23T3boFEjJpQNSj0WVR28n3Lq1UbL2c3Gc6ncYpIkwdu\n kic9NLrUKhvm33huh23+nn3GcgGOHK8NaLsHE6yA01Mom8HYSKLvLCNb4+jf4ZmO/Hhu\n utx9ll7Myll7T7O3s2n2oQsVehFCAIqvbforhV6pi2fPxGpkFQ47DQiR4vukkz+rf9aH\n vOu2ALP1vqC0IXbGAXRyZkjC7XCX7GH0RFfh1FWzwIyqF9J3CgmVH26QJaGSawIvRSdh\n 2I1A==","X-Gm-Message-State":"AOJu0YywKfv83iR6RiKvc1dA2SKF+z1gvAzvzamMXfzAL4N+PfDyE0mg\n 28c53rCXzblR5bq4MXaDrJWNHDXwj3faPaeRLWlE0/KaPzOc+vBJH0sjE6iGebK49iBPAri3dbG\n Fd+qrkQU7WAqcMzU=","X-Received":["by 2002:a5d:56ca:0:b0:31f:d8b3:e9f5 with SMTP id\n m10-20020a5d56ca000000b0031fd8b3e9f5mr9146172wrw.34.1696237062448;\n Mon, 02 Oct 2023 01:57:42 -0700 (PDT)","by 2002:a5d:56ca:0:b0:31f:d8b3:e9f5 with SMTP id\n m10-20020a5d56ca000000b0031fd8b3e9f5mr9146156wrw.34.1696237062088;\n Mon, 02 Oct 2023 01:57:42 -0700 (PDT)"],"X-Google-Smtp-Source":"\n AGHT+IFrzNVxIOfJOk15r++VqOXoeT1XnIyZuejaeShvDOTKPjy99A5uUDFfqMClE2pthwX0F/cLPg==","Message-ID":"<56cec8a9-f4bb-5e9e-a1c4-223359f8b491@redhat.com>","Date":"Mon, 2 Oct 2023 10:57:40 +0200","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Subject":"Re: [PATCH v4 16/18] virtio-mem: Expose device memory dynamically via\n multiple memslots if enabled","Content-Language":"en-US","To":"\"Maciej S. Szmigiero\" ","Cc":"Paolo Bonzini , Igor Mammedov ,\n Xiao Guangrong ,\n \"Michael S. Tsirkin\" , Peter Xu ,\n\t=?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,\n Eduardo Habkost ,\n Marcel Apfelbaum ,\n Yanan Wang , Michal Privoznik ,\n\t=?utf-8?q?Daniel_P_=2E_Berrang=C3=A9?= ,\n Gavin Shan , Alex Williamson ,\n Stefan Hajnoczi , kvm@vger.kernel.org,\n qemu-devel@nongnu.org","References":"<20230926185738.277351-1-david@redhat.com>\n <20230926185738.277351-17-david@redhat.com>\n <11c6efbd-b794-4a05-9c51-4928fb545db4@maciej.szmigiero.name>","From":"David Hildenbrand ","Organization":"Red Hat","In-Reply-To":"<11c6efbd-b794-4a05-9c51-4928fb545db4@maciej.szmigiero.name>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","Received-SPF":"pass client-ip=170.10.133.124; envelope-from=david@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-51","X-Spam_score":"-5.2","X-Spam_bar":"-----","X-Spam_report":"(-5.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n NICE_REPLY_A=-3.058, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01,\n RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]