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 641B993F5F for ; Wed, 10 Apr 2024 12:10:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 452D5B78D for ; Wed, 10 Apr 2024 12:09:34 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 10 Apr 2024 12:09:33 +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 05CD443A7D for ; Wed, 10 Apr 2024 12:09:33 +0200 (CEST) Message-ID: <5c533d64-d65f-448f-b3f8-5e7375582e5c@proxmox.com> Date: Wed, 10 Apr 2024 12:09:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Dominik Csapak , 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> <9e87808a-dfac-4909-9a35-302c680d6a4b@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <9e87808a-dfac-4909-9a35-302c680d6a4b@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.073 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 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: Wed, 10 Apr 2024 10:10:04 -0000 Am 02.04.24 um 11:30 schrieb Dominik Csapak: >>> 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) > Maybe it's enough to mention in the description that the mdev property from the hostpciN config will win? If we want to go one step further, we could add warnings when mdev from the mapping and whether mdev in the hostpciN is set do not agree. But the latter probably only makes sense if we do want to enforce it at some point. >>> +    '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 => {}, >>>       }; >>>   } > >