Comment 2 for bug 1613434

Revision history for this message
Brent Eagles (beagles) wrote :

I'll see about the logs. In the meantime, I'll clarify. I should've indicated that calls mentioned in the bug report are simulations of what actually gets called in the environment. That is:

print filter.specs[0].address.match(dev_dict['address'], dev_dict.get('parent_addr'))

is the address match part of the PciDeviceSpec::match() method in nova/pci/devspec.py

dev_dict = jsonutils.loads('{"dev_id": "pci_0000_05_00_1", "product_id": "154d", "dev_type": "type-PF", "numa_node": 0, "vendor_id": "8086", "label": "label_8086_154d", "address": "0000:05:00.1"}')

is just initializing a device dict from an extract from the debug logs of the resource_tracker when it queries the hypervisor for the list of devices

filter = nova.pci.whitelist.Whitelist(['[{"address":"0000:05:00.1", "product_id":"154d", "vendor_id":"8086", "physical_network":"physnet", "device_type":"type-PF"}]'])

Is simply taking the whitelist from the configuration file, and directly instantiating the whitelist object with it.

This is all to simulate with basically real info from the environment in question what happens when
ResourceTracker::_update_available_resource() instantiates it's pci_tracker member with PciDevTracker. After it instantiates it calls PciDevTracker::update_devices_from_hypervisor_resources() with a complete list of serialized devices obtained by calling libvirt (I included just the relevant one). This in turn calls WhiteList::device_assignable for each device. WhiteList::device_assignable goes through it's list of entries (which I include just one - the one that should match), if there is a match, the PciDevTracker will add it to its list of devices. The example calls and data I provided indicate that the PCI address matching doesn't make sense for PFs. An examination of the call on PciAddress::match() where if the second parameter to match call() representing the parent's physical PCI address is None, and the address is for a physical function - which it is - then False is returned and the device is skipped.

Ultimately, the problem might lie elsewhere, but from an examination of the sample data and the code in question, there does seem to be something wrong with how physical functions are being handled by the code in devspec.py.