From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <d.csapak@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>
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 <f.ebner@proxmox.com>
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=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 => {},
>>>       };
>>>   }
> 
>