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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 4A34590495 for ; Tue, 2 Apr 2024 11:30:53 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 22BC016CD for ; Tue, 2 Apr 2024 11:30:23 +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 ; Tue, 2 Apr 2024 11:30:18 +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 390F544470; Tue, 2 Apr 2024 11:30:18 +0200 (CEST) Message-ID: <9e87808a-dfac-4909-9a35-302c680d6a4b@proxmox.com> Date: Tue, 2 Apr 2024 11:30:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Fiona Ebner , Proxmox VE development discussion References: <20240318111836.1947580-1-d.csapak@proxmox.com> <20240318111836.1947580-2-d.csapak@proxmox.com> <5f27d96a-3443-4000-8771-f513b363a2a7@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <5f27d96a-3443-4000-8771-f513b363a2a7@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.014 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [pci.pm] Subject: Re: [pve-devel] [PATCH guest-common 1/2] mapping: pci: add 'live-migration-capable' flag to mappings 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: Tue, 02 Apr 2024 09:30:53 -0000 On 3/22/24 14:37, Fiona Ebner wrote: > Am 18.03.24 um 12:18 schrieb Dominik Csapak: >> so that we can decide in qemu-server to allow live-migration. >> the driver and qemu must be capable of that, and it's the >> admins responsibility to know and configure that >> > > Nit: "The" and "QEMU" should be capitalized like this. "admins" -> > "admin's". Missing period at the end. > >> Mark the option as experimental in the description. >> >> Signed-off-by: Dominik Csapak >> --- >> src/PVE/Mapping/PCI.pm | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/src/PVE/Mapping/PCI.pm b/src/PVE/Mapping/PCI.pm >> index 19ace98..0866175 100644 >> --- a/src/PVE/Mapping/PCI.pm >> +++ b/src/PVE/Mapping/PCI.pm >> @@ -100,8 +100,16 @@ my $defaultData = { >> maxLength => 4096, >> }, >> mdev => { >> + description => "Marks the device(s) as being capable of providing mediated devices.", >> type => 'boolean', >> optional => 1, >> + default => 0, >> + }, > > Above should be its own patch. Most likely, I'm missing it, but where > exactly does the 'mdev' property from the mapping have an effect? Just > in the UI? At least telling from 'qm showcmd', the 'mdev' property for a > 'hostpciN' VM config entry will not be ignored even if the mapping has > 'mdev=0'. And it's also possible to run 'qm set 112 --hostpci0 > mapping=bar,mdev=foo' without any warning if the mapping has 'mdev=0'. > yeah sorry, i added that but overlooked it when adding the hunks... AFAIR i intended to use the mdev property to safeguard the mapping like we do with the iommu groups, so when it changes, warn the user that the mapping changed (using it with mdevs wouldn't work anyway if that was set but the device wouldn't provide one) aside from that, yes it currently only has effects on the gui, do we maybe want to make that stricter? (would be a breaking change imho) >> + 'live-migration-capable' => { >> + description => "Marks the device(s) as being able to be live-migrated (Experimental).", > > The bit about QEMU and the driver needing to support it should be > mentioned here. > >> + type => 'boolean', >> + optional => 1, >> + default => 0, >> }, >> map => { >> type => 'array', >> @@ -123,6 +131,7 @@ sub options { >> return { >> description => { optional => 1 }, >> mdev => { optional => 1 }, >> + 'live-migration-capable' => { optional => 1 }, >> map => {}, >> }; >> }