From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 28BC19617 for ; Mon, 4 Sep 2023 12:48:56 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 072BADC46 for ; Mon, 4 Sep 2023 12:48:56 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 4 Sep 2023 12:48:53 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7FA1B40C5E; Mon, 4 Sep 2023 12:48:53 +0200 (CEST) Message-ID: <5ee93d17-7a0c-2243-ca7f-1d5cfe6c2718@proxmox.com> Date: Mon, 4 Sep 2023 12:48:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "t.lamprecht@proxmox.com" , "aderumier@odiso.com" References: <20230619072841.38531-1-aderumier@odiso.com> <20230619072841.38531-5-aderumier@odiso.com> <809ca35e-ba06-4326-b830-734096ed0370@proxmox.com> <3e337e38-1a91-8b41-c03c-1f89c8885df7@proxmox.com> <43d759a21681a2bdf8454435d7a8d6a62da0b124.camel@groupe-cyllene.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <43d759a21681a2bdf8454435d7a8d6a62da0b124.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.657 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.473 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH v2 pve-manager 2/2] ui: qemu : memoryedit: add new max && virtio fields X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2023 10:48:56 -0000 Am 02.09.23 um 08:18 schrieb DERUMIER, Alexandre: > Le vendredi 01 septembre 2023 à 12:24 +0200, Fiona Ebner a écrit : >> Am 01.09.23 um 11:48 schrieb Thomas Lamprecht: >>> Am 19/06/2023 um 09:28 schrieb Alexandre Derumier: >>>> +               xtype: 'pveMemoryField', >>>> +               name: 'max', >>>> +               minValue: 65536, >>>> +               maxValue: 4194304, >>>> +               value: '', >>>> +               step: 65536, >>>> +               fieldLabel: gettext('Maximum memory') + ' (MiB)', >>> >>> This huge step size will be confusing to users, there should be a >>> way to have >>> smaller steps (e.g., 1 GiB or even 128 MiB). >>> >>> As even nowadays, with a huge amount of installed memory on a lot >>> of servers, >>> deciding that a (potentially bad actor) VM can use up 64G or 128G >>> is still >>> quite the difference on a lot of setups. Fiona is checking the >>> backend here >>> to see if it might be done with a finer granularity, or what other >>> options >>> we have here. >>> > > I was not think about max size as a security feature, but more to > define the min dimm size to reach this max value. > But indeed, it could be interesting. > Permission-wise there would need to be a difference between changing 'current' and changing 'max', but I'd say that's something for later. >> From a first glance, I think it should be possible. Even if we keep >> the >> restriction "all memory devices should have the same size", which >> makes >> the code easier: >> >> For dimms, we have 64 slots, so I don't see a reason why we can't use >> 64 >> MiB granularity rather than 64 GiB. >> >> > > Note that I think we shouldn't go under 128Mib for dimmsize as it's the > minimum hotplug granularity on linux > > https://docs.kernel.org/admin-guide/mm/memory-hotplug.html > "Memory Hot(Un)Plug Granularity > Memory hot(un)plug in Linux uses the SPARSEMEM memory model, which > divides the physical memory address space into chunks of the same size: > memory sections. The size of a memory section is architecture > dependent. For example, x86_64 uses 128 MiB and ppc64 uses 16 MiB." > Okay, I see. Then let's go with the "create with support for more initially and have API deny requests bigger than max"-approach. > Static mem is already setup at 4GB, so I really don't known if we want > 128mib dimm size in 2023 ? > > I'm really don't have tested windows and other OS under 1 gbit dimm > size. > The current implementation starts out with adding 512 MiB-sized dimms, so at least those should be fine.