lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+AkT2g-Xt+hcpoh2ETx70v0mzV6m=-5zpxJrhs2C8WF--kmWw@mail.gmail.com>
Date:	Wed, 18 Mar 2015 11:40:41 -0400
From:	jacob jacob <opstkusr@...il.com>
To:	Bandan Das <bsd@...hat.com>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	QEMU Developers <qemu-devel@...gnu.org>,
	kvm-devel <kvm@...r.kernel.org>,
	Stefan Assmann <sassmann@...hat.com>, netdev@...r.kernel.org
Subject: Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)

On Wed, Mar 18, 2015 at 11:24 AM, Bandan Das <bsd@...hat.com> wrote:
> [Ccing netdev and Stefan]
> Bandan Das <bsd@...hat.com> writes:
>
>> jacob jacob <opstkusr@...il.com> writes:
>>
>>> On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das <bsd@...hat.com> wrote:
>>>> jacob jacob <opstkusr@...il.com> writes:
>>>>
>>>>> I also see the following in dmesg in the VM.
>>>>>
>>>>> [    0.095758] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
>>>>> [    0.096006] acpi PNP0A03:00: ACPI _OSC support notification failed,
>>>>> disabling PCIe ASPM
>>>>> [    0.096915] acpi PNP0A03:00: Unable to request _OSC control (_OSC
>>>>> support mask: 0x08)
>>>> IIRC, For OSC control, after BIOS is done with (whatever initialization
>>>> it needs to do), it clears a bit so that the OS can take over. This message,
>>>> you are getting is a sign of a bug in the BIOS (usually). But I don't
>>>> know if this is related to your problem. Does "dmesg | grep -e DMAR -e IOMMU"
>>>> give anything useful ?
>>>
>>> Do not see anything useful in the output..
>>
>> Ok, Thanks. Can you please post the output as well ?
>>
>>>>> [    0.097072] acpi PNP0A03:00: fail to add MMCONFIG information,
>>>>> can't access extended PCI configuration space under this bridge.
>>>>>
>>>>> Does this indicate any issue related to PCI passthrough?
>>>>>
>>>>> Would really appreciate any input on how to bebug this further.
>>>>
>>>> Did you get a chance to try a newer kernel ?
>>> Currently am using 3.18.7-200.fc21.x86_64 which is pretty recent.
>>> Are you suggesting trying the newer kernel just on the host? (or VM too?)
>> Both preferably to 3.19. But it's just a wild guess. I saw i40e related fixes,
>> particularly "i40e: fix un-necessary Tx hangs" in 3.19-rc5. This is not exactly
>> what you are seeing but I was still wondering if it could help.
>
> Actually, Stefan suggests that support for this card is still sketchy
> and your best bet is to try out net-next
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git
>
> Also, could you please post more information about your hardware setup
> (chipset/processor/firmware version on the card etc) ?

Host CPU : Model name:            Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz

Manufacturer Part Number:  XL710QDA1BLK
Ethernet controller: Intel Corporation Ethernet Controller XL710 for
40GbE QSFP+ (rev 01)
 #ethtool -i enp9s0
driver: i40e
version: 1.2.6-k
firmware-version: f4.22 a1.1 n04.24 e800013fd
bus-info: 0000:09:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


> Thanks,
> Bandan
>
>> Meanwhile, I am trying to get hold of a card myself to try and reproduce
>> it at my end.
>>
>> Thanks,
>> Bandan
>>
>>>>> On Fri, Mar 13, 2015 at 10:08 AM, jacob jacob <opstkusr@...il.com> wrote:
>>>>>>> So, it could be the i40e driver then ? Because IIUC, VFs use a separate
>>>>>>> driver. Just to rule out the possibility that there might be some driver fixes that
>>>>>>> could help with this, it might be a good idea to try a 3.19 or later upstream
>>>>>>> kernel.
>>>>>>>
>>>>>>
>>>>>> I tried with the latest DPDK release too (dpdk-1.8.0) and see the same issue.
>>>>>> As mentioned earlier, i do not see any issues at all when running
>>>>>> tests using either i40e or dpdk on the host itself.
>>>>>> This is the reason why i am suspecting if it is anything to do with KVM/libvirt.
>>>>>> Both with regular PCI passthrough and VF passthrough i see issues. It
>>>>>> is always pointing to some issue with packet transmission. Receive
>>>>>> seems to work ok.
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 12, 2015 at 8:02 PM, Bandan Das <bsd@...hat.com> wrote:
>>>>>>> jacob jacob <opstkusr@...il.com> writes:
>>>>>>>
>>>>>>>> On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das <bsd@...hat.com> wrote:
>>>>>>>>> jacob jacob <opstkusr@...il.com> writes:
>>>>>>>>>
>>>>>>>>>>  Hi,
>>>>>>>>>>
>>>>>>>>>>  Seeing failures when trying to do PCI passthrough of Intel XL710 40G
>>>>>>>>>> interface to KVM vm.
>>>>>>>>>>      0a:00.1 Ethernet controller: Intel Corporation Ethernet
>>>>>>>>>> Controller XL710 for 40GbE QSFP+ (rev 01)
>>>>>>>>>
>>>>>>>>> You are assigning the PF right ? Does assigning VFs work or it's
>>>>>>>>> the same behavior ?
>>>>>>>>
>>>>>>>> Yes.Assigning VFs worked ok.But this had other issues while bringing down VMs.
>>>>>>>> Interested in finding out if PCI passthrough of 40G intel XL710
>>>>>>>> interface is qualified in some specific kernel/kvm release.
>>>>>>>
>>>>>>> So, it could be the i40e driver then ? Because IIUC, VFs use a separate
>>>>>>> driver. Just to rule out the possibility that there might be some driver fixes that
>>>>>>> could help with this, it might be a good idea to try a 3.19 or later upstream
>>>>>>> kernel.
>>>>>>>
>>>>>>>>>> From dmesg on host:
>>>>>>>>>>
>>>>>>>>>>> [80326.559674] kvm: zapping shadow pages for mmio generation wraparound
>>>>>>>>>>> [80327.271191] kvm [175994]: vcpu0 unhandled rdmsr: 0x1c9
>>>>>>>>>>> [80327.271689] kvm [175994]: vcpu0 unhandled rdmsr: 0x1a6
>>>>>>>>>>> [80327.272201] kvm [175994]: vcpu0 unhandled rdmsr: 0x1a7
>>>>>>>>>>> [80327.272681] kvm [175994]: vcpu0 unhandled rdmsr: 0x3f6
>>>>>>>>>>> [80327.376186] kvm [175994]: vcpu0 unhandled rdmsr: 0x606
>>>>>>>>>
>>>>>>>>> These are harmless and are related to unimplemented PMU msrs,
>>>>>>>>> not VFIO.
>>>>>>>>>
>>>>>>>>> Bandan
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>>>>>>> the body of a message to majordomo@...r.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ