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 A3242907A7 for ; Fri, 2 Sep 2022 11:03:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8D6032DC79 for ; Fri, 2 Sep 2022 11:02:30 +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 ; Fri, 2 Sep 2022 11:02:29 +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 D058B435D5; Fri, 2 Sep 2022 11:02:28 +0200 (CEST) Message-ID: Date: Fri, 2 Sep 2022 11:02:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Thunderbird/105.0 Content-Language: en-US To: "DERUMIER, Alexandre" , Proxmox VE development discussion References: <20220825092440.1810328-1-d.csapak@proxmox.com> <20220825092440.1810328-18-d.csapak@proxmox.com> <40540b19-6675-8ec9-5ac0-0163814bfe92@groupe-cyllene.com> <7d0ed948-8cd9-0a68-afee-764d67852e30@groupe-cyllene.com> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.093 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH qemu-server v2 12/13] fix #3574: enable multi pci device mapping from config 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: Fri, 02 Sep 2022 09:03:00 -0000 On 8/27/22 18:09, DERUMIER, Alexandre wrote: > Le 26/08/22 à 08:39, Dominik Csapak a écrit : >> On 8/25/22 16:53, DERUMIER, Alexandre wrote: >>>   > root@pve2:~# qm start 101 >>>   > ignoring mediated device with multifunction device >>> >>> ok, it's simply that indeed I have specify a multifunction path >>> "0000:02". >>> >>> I think it should better/safe to die here, instead to simply warn and >>> continue. >> i agree die'ing here is better, for the mapped case we could do that now, >> but for the old case of a pciid we can't (for backwards compat) until 8.0 >> >> [snip] >> >>>> >>>> maybe not related, but after that, stop/start are not working anymore >>>> >>>> root@pve2:~# qm stop 101 >>>> PCI device mapping invalid (hardware probably changed): 'mdev' >>>> configured but should not be >>>> >>>> root@pve2:~# qm start 101 >>>> PCI device mapping invalid (hardware probably changed): 'mdev' >>>> configured but should not be >>>> > > I can reproduce this 100%, if the start with mdev of multifunction path > fallback to classic pci passthrough. > > and I was able to configure this on the vm pci configuration. > No sure, maybe I have configure the mapping with single function, > configure the vm, then change the mapping with multifunction. > > > > > I see that currently it's possible to mix multifunction, single > function devices in same mapping group. > I wonder if it couldn't be better to add an option on the group, to > define "multifunction=on/off , mdev=on/off. > > then only add devices with theses 2 options, don't mix different kind of > devices. in my current version (here locally) i changed it so that for multifunction devices mdev is always false (since that wouldn't make sense anyway) this way you cannot mix them anymore since the attributes must match for all ids (i don't really like a seperate multifunction/mdev toggle; but we could implement a filter for the grid in the gui later) > > Also, multifuction && mdev can't be changed on the group if devices are > already in the group. > > what do you mean by that? the attributes (vendor/mdev/...) are only meant as read only to verify that the ids are really the device the user configured mdev itself will be configured in the vm config then