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. -- yamahata
