From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964871AbcJYTk7 (ORCPT ); Tue, 25 Oct 2016 15:40:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49974 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752488AbcJYTk5 (ORCPT ); Tue, 25 Oct 2016 15:40:57 -0400 Subject: Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching To: Alex Williamson References: <20161025182419.22910-1-lersek@redhat.com> <20161025124218.2696e55a@t450s.home> Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Andrei Grigore , Bjorn Helgaas , Jayme Howard From: Laszlo Ersek Message-ID: Date: Tue, 25 Oct 2016 21:40:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 25 Oct 2016 19:40:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/25/16 21:24, Laszlo Ersek wrote: > On 10/25/16 20:42, Alex Williamson wrote: >> FWIW, I think the reason >> this hasn't been done to date is that PCI bus addresses (except for >> root bus devices) are not stable. Depending on the system, the address >> of a given device may change, not only based on the slot where the >> device is installed, but whether other devices in other slots are >> populated. > > I agree. > > However, while the addresses are not stable in the face of hardware > changes, I think the addresses don't change haphazardly (that is, > without hardware changes). > > So, if you plug in another card, your current pci-stub.except=... > parameter might become invalid; but that's not very different from the > case when you plug in the second instance of a preexistent card right > now -- then the pci-stub.ids=... filter won't match uniquely anymore, > and assignment vs. host-side use might not work as intented. Sorry about the self-followup; I just wanted to add -- although it might not carry a lot of weight for the host kernel -- that the libvirt domain XML hard-codes the host-side PCI BDF anyway, for assigned devices: http://libvirt.org/formatdomain.html#elementsHostDev """
... ... source The source element describes the device as seen from the host using the following mechanism to describe: ... pci PCI devices can only be described by their address. """ Thanks Laszlo