At 09/29/2011 10:56 PM, Laine Stump Write: > On 09/29/2011 10:30 AM, Laine Stump wrote: >> On 09/27/2011 05:13 AM, Daniel P. Berrange wrote: >>> When we originally enabled multifunction for all PCI devices, we did so >>> in the belief that this was effectively a no-op for guest OSes. ie it >>> should not have changed guest OS behaviour at all, unless multiple >>> devices >>> were actually inserted in the slot. >>> >>> Evidentally this turns out to be incorrect. In other words we introduced >>> a guest ABI change. This is very bad, because our stated goal is to have >>> a stable guest ABI across libvirt& QEMU releases. >>> >>> Thus IMHO we need to disable *all* setting of the 'multifunction=on' >>> parameter for all guests by default, to unbreak the ABI compatibility. >>> >>> Then we should introduce a new parameter 'multifunction='on' in the >>> <address type=pci> element to allow it to be optionally enabled per >>> device. >> >> >> A couple of questions: >> >> 1) Is it possible/useful to have function > 0 without multifunction=on >> in the qemu commandline? >> >> 2) If the answer to (1) is "No", if the XML has function > 0 but no >> multifunction=on, should we implicitly add multifunction=on, or should >> we log an error? > > Also: > > 3) if you explicitly/(implicitly?) set multifunction on for one function > of a slot, does qemu automatically do so for other functions on the slot > (ie, if you have a device that uses slot 1 function 1 (and turns on > multifunction), then will slot 1 function 0 automatically have > multifunction turned on too?) IIRC, qemu does not do it. If bit 7 in the Header Type register of function 1 is 1, and bit 7 in the Header Type register of function 0 is 0, it's a single device, and you will not see the other function on the guest. Thanks Wen Congyang > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list