[vfio-users] vfio_pci_read_config failed: Bad address

[Ronnie Swanink]

Hello,

The kernel options are:
[root at localhost ronnie]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.3.0-1.vanilla.mainline.knurd.1.fc23.x86_64 
root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root 
rd.lvm.lv=fedora/swap rhgb quiet intel_iommu=on rd.driver.pre=vfio-pci

See http://pastebin.com/GwhWbshH for a dump of dmesg

And to be sure: http://pastebin.com/4kxSuqzA for a dump with the 
standard 4.2.5-300 kernel.

Ronnie


On 17-11-2015 22:55, Alex Williamson wrote:
> On Tue, 2015-11-17 at 22:35 +0100, Ronnie Swanink wrote:
>> Hello,
>> 
>> For the last week I've been trying to get GPU passthrough to work. My
>> goal is to have a simple MSI Geforce 210 as the host graphics adapter,
>> and pass a MSI GTX 970 GAMING to a Windows 8 guest. However, I can't 
>> get
>> it to work. The 970 does give output when the drivers are not 
>> installed,
>> but after installing the drivers qemu gives me the following error 
>> when
>> Windows boots (the vm restarts after that and Windows goes into
>> automatic recovery):
>> 
>> 2015-11-17T21:08:59.910448Z qemu-system-x86_64:
>> vfio_pci_read_config(0000:02:00.0, 0x60c, 0x4) failed: Bad address
>> 2015-11-17T21:08:59.910566Z qemu-system-x86_64:
>> vfio_pci_read_config(0000:02:00.0, 0x610, 0x4) failed: Bad address
>> 2015-11-17T21:09:00.404715Z qemu-system-x86_64:
>> vfio_pci_read_config(0000:02:00.0, 0x150, 0x4) failed: Bad address
> 
> 
> Note that these (and the bazillion others included) are all to offsets
>> = 0x100, PCI extended config space.
> 
>> 
>> My hardware (as you can see, the 970 is claimed by vfio-pci):
>> 
>> [root at localhost Documents]# lspci -v
> 
> And none of the listing here show any extended config space for 
> devices.
> For example, your GPU should look more like this:
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce
> GTX 750] (rev a2) (prog-if 00 [VGA controller])
> 	Subsystem: eVga.com. Corp. Device 2753
> 	Flags: fast devsel, IRQ 16
> 	Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
> 	Memory at e0000000 (64-bit, prefetchable) [size=256M]
> 	Memory at f0000000 (64-bit, prefetchable) [size=32M]
> 	I/O ports at e000 [size=128]
> 	Expansion ROM at f7000000 [disabled] [size=512K]
> 	Capabilities: [60] Power Management version 3
> 	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
> 	Capabilities: [78] Express Legacy Endpoint, MSI 00
> 	Capabilities: [100] Virtual Channel
> 	Capabilities: [250] Latency Tolerance Reporting
> 	Capabilities: [258] L1 PM Substates
> 	Capabilities: [128] Power Budgeting <?>
> 	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 
> <?>
> 	Capabilities: [900] #19
> 	Kernel driver in use: vfio-pci
> 	Kernel modules: nouveau
> 
> So, there's likely a QEMU bug that we're passing through a config
> request beyond the end of what the kernel reported the size of config
> space to be, and that results in a -EFAULT from the kernel, but there
> must be a reason that extended config space is not present.  Assuming
> this happens on Fedora kernels, what kernel options are you providing?
> A pastebin of dmesg might provide some clues.  Things like pci=nommconf
> would certainly explain this.  Thanks,
> 
> Alex