From: "Goutham GS" <goutham@zadarastorage.com>
To: "'Alex Williamson'" <alex.williamson@redhat.com>
Cc: <kvm@vger.kernel.org>
Subject: RE: vfio issue in qemu 2.5
Date: Thu, 4 Feb 2016 23:53:06 +0530 [thread overview]
Message-ID: <10e501d15f79$1ae03d80$50a0b880$@zadarastorage.com> (raw)
In-Reply-To: <20160204100207.2c953cc3@t450s.home>
Hello Alex,
Thanks for your quick response.
Unfortunately we are tied to this kernel. Probably we can move to 3.19, if
we are sure of the benefits . Not sure.
Regarding dmesg, there is nothing on the host and the VM never came up to
the point where we could collect dmesg.
Regards,
Goutham.
-----Original Message-----
From: Alex Williamson [mailto:alex.williamson@redhat.com]
Sent: Thursday, February 4, 2016 10:32 PM
To: Goutham GS <goutham@zadarastorage.com>
Cc: kvm@vger.kernel.org
Subject: Re: vfio issue in qemu 2.5
On Thu, 4 Feb 2016 20:31:17 +0530
"Goutham GS" <goutham@zadarastorage.com> wrote:
> Hi All,
>
> We are facing a vfio issue on qemu 2.5. Really appreciate any help or
> pointers. Details are as below:
>
> We are using qemu 2.5 compiled out of git commit
> 0b0571dd246871f18b7d64b5279511e91e2a7bf6 and are using Linux Kernel
> 3.18.19 for both host and the VM. We are also using KVM VM with
> pci-assign'ed SRIOV VF interfaces.
>
> The issue happens once in a while when a running VM is rebooted. On
> boot, the VM hits the following error and stops.
>
> qemu-system-x86_64: -device
> vfio-pci,host=04:00.7,id=hostdev2,bus=pci.0,addr=0x9: vfio: failed to
> set iommu for container: Bad address
> qemu-system-x86_64: -device
> vfio-pci,host=04:00.7,id=hostdev2,bus=pci.0,addr=0x9: vfio: failed to
> setup container for group 40
> qemu-system-x86_64: -device
> vfio-pci,host=04:00.7,id=hostdev2,bus=pci.0,addr=0x9: vfio: failed to
> get group 40
> qemu-system-x86_64: -device
> vfio-pci,host=04:00.7,id=hostdev2,bus=pci.0,addr=0x9: Device
> initialization failed
>
> Strange thing is, once this error is hit, no further VMs can be
> spawned on the host and all of them run into the same problem.
> However a reboot of the host appears to solve the issue.
>
> I have attached the relevant logs.
Is it possible to try a newer kernel on the host? "Bad address" is -EFAULT,
but I'm not actually able to spot a return path for the VFIO_SET_IOMMU ioctl
that returns -EFAULT. Is there anything in dmesg when this triggers?
Thanks,
Alex
next prev parent reply other threads:[~2016-02-04 18:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 15:01 vfio issue in qemu 2.5 Goutham GS
2016-02-04 17:02 ` Alex Williamson
2016-02-04 18:23 ` Goutham GS [this message]
2016-02-05 5:19 ` Goutham GS
2016-02-05 6:02 ` Alex Williamson
2016-02-05 6:30 ` Goutham GS
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='10e501d15f79$1ae03d80$50a0b880$@zadarastorage.com' \
--to=goutham@zadarastorage.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.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