device_type of PCI alias config could be mismatched
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Wishlist
|
Unassigned |
Bug Description
Currently, to use PCI passthrough functionality admin should specify the alias of PCI devices and the format is like below
alias = { "vendor_id":"8086", "product_
What I think confusing for this configuration is that there is just one "device_type" for the device. I assume that device_type is not needed to the device be identified since libvirt made the device_type for one device.
IOW, I suspects it never happens like below.
alias = { "vendor_id":"8086", "product_
alias = { "vendor_id":"8086", "product_
I strongly believe the PCI device having 8086:1528 ID is just already set the unique device_type., I'm not 100% sure though.
So my point is it's better to delete device_type attribute for the config so that admin does not care about the device type. I think it's big barrier to use PCI passthrough functionality for whom does not familiar with the concept.
Thanks.
tags: | added: pci |
the device_type is optional but if set it will be checked
https:/ /github. com/openstack/ nova/blob/ 51e3787bf89f19a f8a9d37288a6373 1563c92fca/ nova/pci/ request. py#L136- L138
type-pci is not intended for fore use with device that are capable of sriov and exits primarly for use with pci device that are not nics.
type-PCI is reserved for device that will be passthough via the pci aliase in the falvor that should not be request able by neutron based sriov port.
it is generally used for gpus, crypto cards like intel QAT devices or nics that are not managed by neutron and do not support sriov.
type-PF is use for device that weill be request using neutron vnic_type= direct- physical.
and
type-VF is used for edvice that eill be requested using neutron vnic_type=direct.
type-pf and type-pf may also be used for non nic device but in that case the physical_network tage must
not be set in the pci whitelist.
when we process a neutron prot we translate form the port vnic type to teh correct device_type here. /github. com/openstack/ nova/blob/ 212607dc6feaf31 1ba92295fd07363 b3ee9ae010/ nova/network/ neutronv2/ api.py# L2046-L2060
https:/
when enumarting the devices in the libvirt virt dirver here /opendev. org/openstack/ nova/src/ branch/ master/ nova/virt/ libvirt/ driver. py#L6076- L6113
https:/
we interperat the device capabilities to determine if the which type to use when reporting the device.
depending on the nic, firmware and and dirver otions the present of the virtual_fucntion capablity in the
pci capablityis reported by libvirt can change.
that is to say on older generation intel nicantics such as the intel 82599 series
the presence of the virtual_fucntion cabpablity was ondition on if data center bridgeing
was enabled in teh fireware.
in data center bridgeing mode sriov was disabled to allow VMDQ to be used so even with the same vendor and product id
the device type can change.
when a device support sriov and is listed as a PF there are also addtional checks that the schduler and pci resouce tracker must perfrom to determing that a PF is availble for assignemnt to a vm. The most import being the pci resouce track must first confirm that the PF etiher has no VFs or that all VFs are free.
For type-PCI we do not have to do that check as we know it does not support sriov and thereforce will not have VF that could be in use.