On 2012-01-17 14:23, Alex Williamson wrote:
>
>
> ----- Original Message -----
>> On 2012-01-16 18:11, Alex Williamson wrote:
>>> The core PCI code sets the multifunction bit in the header before
>>> calling the device initfn. For device assignment, we're blasting
>>> that value with the actual hardware value, so nobody sees the
>>> additional functions if the devices isn't physically multifunction.
>>> Switch the HEADER_TYPE to a fully emulated field (all read-only
>>> anyway) and add setting and clearing of the multifunction bit to
>>> match qemu directive.
>>>
>>> Signed-off-by: Alex Williamson <alex.william...@redhat.com>
>>> ---
>>>
>>> hw/device-assignment.c | 8 +++++++-
>>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
>>> index 2a9e66d..7f4a5ec 100644
>>> --- a/hw/device-assignment.c
>>> +++ b/hw/device-assignment.c
>>> @@ -540,6 +540,13 @@ again:
>>> fprintf(stderr, "%s: read failed, errno = %d\n", __func__,
>>> errno);
>>> }
>>>
>>> + /* Restore or clear multifunction, this is always controlled
>>> by qemu */
>>> + if (pci_dev->dev.cap_present & QEMU_PCI_CAP_MULTIFUNCTION) {
>>> + pci_dev->dev.config[PCI_HEADER_TYPE] |=
>>> PCI_HEADER_TYPE_MULTI_FUNCTION;
>>> + } else {
>>> + pci_dev->dev.config[PCI_HEADER_TYPE] &=
>>> ~PCI_HEADER_TYPE_MULTI_FUNCTION;
>>> + }
>>> +
>>
>> Why have this in get_*real*_device? Why not fix this up at the caller
>> site, i.e. in assigned_initfn? Just for consistency, not a functional
>> issue.
>
> I chose here because we've just overwritten the emulated config space and we
> then proceed to clean out the BAR registers. As this is close to the point
> where it gets trashed and we're doing other fixup, it seems appropriate.
OK.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
