From: Bandan Das <bsd@redhat.com>
To: jacob jacob <opstkusr@gmail.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)
Date: Mon, 16 Mar 2015 14:12:36 -0400 [thread overview]
Message-ID: <jpg1tko7qwb.fsf@redhat.com> (raw)
In-Reply-To: <CA+AkT2gXouCdMWzRJBY0jYi6O61OjDnNf7XGnfLzhYkJCe00mg@mail.gmail.com> (jacob jacob's message of "Mon, 16 Mar 2015 12:31:42 -0400")
jacob jacob <opstkusr@gmail.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 ?
> [ 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 ?
> On Fri, Mar 13, 2015 at 10:08 AM, jacob jacob <opstkusr@gmail.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@redhat.com> wrote:
>>> jacob jacob <opstkusr@gmail.com> writes:
>>>
>>>> On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das <bsd@redhat.com> wrote:
>>>>> jacob jacob <opstkusr@gmail.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@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-03-16 18:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 16:17 [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM) jacob jacob
2015-03-12 16:26 ` Alex Williamson
2015-03-12 16:36 ` jacob jacob
2015-03-12 19:07 ` Bandan Das
2015-03-12 23:11 ` jacob jacob
2015-03-13 0:02 ` Bandan Das
2015-03-13 14:08 ` jacob jacob
2015-03-16 16:31 ` jacob jacob
2015-03-16 18:12 ` Bandan Das [this message]
2015-03-16 18:24 ` jacob jacob
2015-03-16 19:49 ` Bandan Das
2015-03-16 19:58 ` jacob jacob
2015-03-18 15:24 ` Bandan Das
2015-03-18 15:40 ` jacob jacob
2015-03-18 22:01 ` Shannon Nelson
2015-03-18 22:06 ` Shannon Nelson
2015-03-19 8:15 ` Stefan Assmann
2015-03-19 14:00 ` jacob jacob
2015-03-19 14:04 ` jacob jacob
2015-03-19 14:18 ` Stefan Assmann
2015-03-20 20:55 ` jacob jacob
2015-03-23 7:19 ` Stefan Assmann
2015-03-24 14:13 ` jacob jacob
2015-03-24 14:53 ` Shannon Nelson
2015-03-24 15:04 ` jacob jacob
2015-03-26 1:00 ` Shannon Nelson
2015-03-19 16:26 ` Shannon Nelson
2015-03-19 21:04 ` jacob jacob
2015-03-19 21:42 ` Shannon Nelson
2015-03-19 21:53 ` jacob jacob
2015-03-19 23:37 ` jacob jacob
-- strict thread matches above, loose matches on Subject: below --
2015-03-12 16:11 jacob jacob
2015-03-12 16:13 ` jacob jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jpg1tko7qwb.fsf@redhat.com \
--to=bsd@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=opstkusr@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).