From: Alex Williamson <alex.williamson@redhat.com>
To: Shyam <shyam.kaushik@gmail.com>, kvm@vger.kernel.org
Subject: Re: KVM pci-assign - iommu width is not sufficient for mapped address
Date: Thu, 07 Jan 2016 07:10:12 -0700 [thread overview]
Message-ID: <1452175812.29599.132.camel@redhat.com> (raw)
In-Reply-To: <CABYsEFdjH+mY7+a2VvpF4S=jF_XPac6iDYFWr7WDNHYKZB_mpw@mail.gmail.com>
On Thu, 2016-01-07 at 15:48 +0530, Shyam wrote:
> Hi All,
>
> We are using Linux Kernel 3.18.19 for running KVM VM's with
> pci-assign'ed SRIOV VF interfaces.
>
> We understand that VFIO is the new recommended way, but unfortunately
> it reduces performance significantly on our IO workloads (upto the
> order of 40-50%) when compared to pci-passthrough. We run trusted
> VM's
> & expose services to the external world. Since we control the VM's,
> IOMMU security with VFIO is not exactly mandatory, but performance is
> much more important that we get with pci-assign.
>
> We observe a strange behaviour that has already been discussed in
> this
> forum which is upon a VM spawn it causes the following fault
> resulting
> in qemu-kvm crashing
>
> Jan 7 09:41:57 q6-s1 kernel: [90037.228477] intel_iommu_map: iommu
> width (48) is not sufficient for the mapped address
> (fffffffffe001000)
> Jan 7 09:41:57 q6-s1 kernel: [90037.308229]
> kvm_iommu_map_address:iommu failed to map pfn=95000
>
> We observe that this problem happens only if guest linux running 3.5
> kernel is spun up & this problem doesnt happen when running guest
> linux with 3.6 kernel (i.e. all guest with kernels like 3.2 etc up
> till 3.5 causes the above crash whereas any guest kernel >=3.6 doesnt
> cause this issue).
>
> So something changed between kernel 3.5 to 3.6 in the guest that
> doesnt expose this problem. We have two questions:
> 1 - we understand that VFIO suffered a similar problem & it was fixed
> with https://github.com/qemu/qemu/commit/d3a2fd9b29e43e202315d5e99399
> b99622469c4a.
> Alex Williamson suggested that KVM driver needs an equivalent version
> of the fix. Can anybody suggest hints on where this fix should be
> made?
> 2 - Any insights on what changes in linux kernel between 3.5 to 3.6
> on
> the guest that avoids this problem?
>
> Any helps/input greatly appreciated. Thanks!
Legacy KVM device assignment is deprecated, so I'd suggest your efforts
are better spent reporting and trying to fix any performance difference
you're seeing between pci-assign and vfio-pci. I have a really hard
time believing there's anywhere close to a 40-50% difference. What's
the device? What's the workload? At some point you're likely to find
that pci-assign is no longer even present. Thanks,
Alex
next prev parent reply other threads:[~2016-01-07 14:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 10:18 KVM pci-assign - iommu width is not sufficient for mapped address Shyam
2016-01-07 14:10 ` Alex Williamson [this message]
2016-01-08 4:17 ` Shyam
2016-01-08 4:53 ` Alex Williamson
2016-01-08 6:52 ` Shyam
2016-01-08 18:52 ` Alex Williamson
2016-01-11 10:11 ` Shyam
2016-01-11 23:20 ` Alex Williamson
2016-01-12 7:04 ` Shyam
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=1452175812.29599.132.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=shyam.kaushik@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.