Passei vários dias nisso agora e consegui que o SR-IOV trabalhasse com a placa Mellanox Infiniband usando o firmware mais recente.
As funções virtuais aparecem no Dom0 como
06: 00.1 Controlador de rede: Família Mellanox Technologies MT27500 [Função virtual ConnectX-3] 06: 00.2 Controlador de rede: Família Mellanox Technologies MT27500 [Função virtual ConnectX-3] 06: 00.3 Controlador de rede: Família Mellanox Technologies MT27500 [Função virtual ConnectX-3 ] 06: 00.4 Controlador de rede: Família Mellanox Technologies MT27500 [Função virtual ConnectX-3]
Em seguida, desanexei 06: 00.1 do Dom0 e o designei ao xen-pciback.
Eu passei isso para um domínio de teste do Xen.
lspci dentro do teste DomU mostra:
00: 01.1 Controlador de rede: Família Mellanox Technologies MT27500 [Função virtual ConnectX-3]
Eu tenho os seguintes módulos carregados no DomU
mlx4_ib
rdma_ucm
ib_umad
ib_uverbs
ib_ipoib
A saída dmesg para drivers mlx4 mostra:
[ 11.956787] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011)
[ 11.956789] mlx4_core: Initializing 0000:00:01.1
[ 11.956859] mlx4_core 0000:00:01.1: enabling device (0000 -> 0002)
[ 11.957242] mlx4_core 0000:00:01.1: Xen PCI mapped GSI0 to IRQ30
[ 11.957581] mlx4_core 0000:00:01.1: Detected virtual function - running in slave mode
[ 11.957606] mlx4_core 0000:00:01.1: Sending reset
[ 11.957699] mlx4_core 0000:00:01.1: Sending vhcr0
[ 11.976090] mlx4_core 0000:00:01.1: HCA minimum page size:512
[ 11.976672] mlx4_core 0000:00:01.1: Timestamping is not supported in slave mode.
[ 12.068079] <mlx4_ib> mlx4_ib_add: mlx4_ib: Mellanox ConnectX InfiniBand driver v1.0 (April 4, 2008)
[ 12.184072] mlx4_core 0000:00:01.1: mlx4_ib: multi-function enabled
[ 12.184075] mlx4_core 0000:00:01.1: mlx4_ib: operating in qp1 tunnel mode
Eu até tenho o dispositivo ib0 aparecendo.
ib0 Link encap:UNSPEC HWaddr 80-00-05-49-FE-80-00-00-00-00-00-00-00-00-00-00
inet addr:10.10.10.10 Bcast:10.10.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:2044 Metric:1
RX packets:117303 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:6576132 (6.5 MB) TX bytes:0 (0.0 B)
Posso até executar ping localmente 10.10.10.10.
No entanto, esses pings não são enviados para o tecido de banda infinita.
Parece ser porque o link está inoperante. O ibstat mostra:
CA 'mlx4_0'
CA type: MT4100
Number of ports: 1
Firmware version: 2.30.3000
Hardware version: 0
Node GUID: 0x001405005ef41f25
System image GUID: 0x002590ffff175727
Port 1:
State: Down
Physical state: LinkUp
Rate: 10
Base lid: 9
LMC: 0
SM lid: 1
Capability mask: 0x02514868
Port GUID: 0x0000000000000000
Como faço para obtê-lo? o link domU está UP, mas não o VF?
E a resposta é realmente encontrada aqui: De acordo com este link: http://www.spinics.net/lists/linux-rdma/msg13307.html
O que eu preciso para a porta do VF escravo se tornar ativa? Estou executando o opensm 3.3.13 em uma caixa diferente, isso é novo o suficiente? (o SR-IOV requer algum suporte SM?)
Sim, como observou Hal, no mínimo você precisa do opensm 3.3.14 ( http://marc.info/?l=linux-rdma&m=133819320432335&w=2 ), pois é a primeira versão para oferecer suporte ao alias-guid e outros itens necessários para O SRIOV, 3.3.15 também já está disponível, então você quer a 2ª versão que suporta isso ... basicamente você precisa do link IB para o PPF e o escravo para obter um guia de alias registrado para ele no SM. Nós (equipe da IL) saímos de terça / quarta-feira como feriado, tentaremos obter mais detalhes hoje à noite e, se não, amanhã, com certeza.
Agora eu atualizei o OpenSM e apresentarei um relatório em breve.
EDIT: OK, agora está funcionando. No entanto, estou recebendo uma explosão de log do opensm. O processo OpenSM está escrevendo centenas de entradas por segundo do formulário:
Sep 30 20:36:26 707784 [7DC1700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 707810 [7DC1700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708096 [8DC3700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708119 [8DC3700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708391 [FF5B0700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708421 [FF5B0700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708696 [3DB9700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708719 [3DB9700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
E as mensagens de erro acima desapareceram quando eu reiniciei e dei ao Dom0 mais memória. Atualmente, tenho 2 GB alocados a ele com o desligamento automático. Infelizmente, eles estão de volta sem motivo óbvio. Então, eu fiz uma nova pergunta relacionada a isso aqui
Não sei ao certo por que ele funciona no dom0, mas no meu caso eu tenho que ter o OpenSM rodando no Dom0 que possui os VFs. Eu presumo que isso ocorre porque a instância do OpenSM em execução no Dom0 conhece os VFs e pode publicitá-los enquanto um gerenciador de sub-rede em outro nó não sabe? esse é o meu palpite. Espero que o outro nó xen pegue os VFs também. Isso pode acabar se tornando outra questão. Por enquanto, ele está trabalhando com um único nó Xen.