From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53031 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPd7d-0000Gd-C4 for qemu-devel@nongnu.org; Fri, 18 Jun 2010 11:04:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPd7c-0007Xo-19 for qemu-devel@nongnu.org; Fri, 18 Jun 2010 11:04:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31815) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPd7b-0007Xe-PG for qemu-devel@nongnu.org; Fri, 18 Jun 2010 11:04:43 -0400 Date: Fri, 18 Jun 2010 17:59:45 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH 09/10] pci: set PCI multi-function bit appropriately. Message-ID: <20100618145945.GA26211@redhat.com> References: <81d134b49ddbd54e82648618c0ce4e4d11fb77c3.1276755023.git.yamahata@valinux.co.jp> <20100617093721.GB7912@redhat.com> <20100618024057.GC14658@valinux.co.jp> <20100618124404.GA6397@redhat.com> <20100618133820.GF28863@valinux.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100618133820.GF28863@valinux.co.jp> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: stefano.stabellini@eu.citrix.com, jan.kiszka@siemens.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, kraxel@redhat.com, jean.guyader@gmail.com On Fri, Jun 18, 2010 at 10:38:20PM +0900, Isaku Yamahata wrote: > On Fri, Jun 18, 2010 at 03:44:04PM +0300, Michael S. Tsirkin wrote: > > > > If I understand correctly what this does, it goes over > > > > other functions of the same device, and sets the MULTI_FUNCTION bit > > > > for them if there's more than one function. > > > > Instead, why don't we just set PCI_HEADER_TYPE_MULTI_FUNCTION > > > > in relevant devices? > > > > > > pci address, devfn ,is exported to users as addr property, > > > so users can populate pci function(PCIDevice in qemu) > > > at arbitrary devfn. > > > It means each function(PCIDevice) don't know whether pci device > > > (PCIDevice[8]) is multi function or not. > > > So I chose to handle it in pci generic layer. > > > > > > It can be argued that it's user operation fault and that > > > the missing part is validation checks to catch such user errors. > > > > Exactly. Another part that is missing is a way to hotplug > > a multifunction device. > > Yes, multi function hot plug is also on my wish list. > > > > OTOH I think that hotplug of separate functions has no chance to work, > > so users are better off getting an error. > > > > > But I prefer more flexible and more user friendly way. > > > > I think that most users would only add many functions > > to a device as a result of an error. > > > > If we really want the ability to put unrelated devices > > as functions in a single one, let's just add > > a 'multifunction' qdev property, and validate that > > it is set appropriately. > > I think "unrelated" is policy. There is no obvious way to determine > which functions can be in a same device. > For example, popular chipset contains isa bridge, ide controller, > usb controller, sound and modem in a single device as functions. > It's up to hardware designer policy which functions are grouped into > a device. > > So qemu should be able to populate any function in a device, > and leave such policy check to higher level tool like libvirt/virt-manager. Fine. But tweaking one device's config when another one is added does not lead to robust code. Let's just require that users declare devices as multifunction, and verify this. -- MST