Bug 499261 - KVM PCI device assignment fails with "assigned_dev_register_regions: Error: Couldn't mmap 0xffa40000!"
KVM PCI device assignment fails with "assigned_dev_register_regions: Error: C...
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
Fedora Extras Quality Assurance
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
Reported: 2009-05-05 16:48 EDT by Mark McLoughlin
Modified: 2009-05-06 10:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-06 07:03:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark McLoughlin 2009-05-05 16:48:44 EDT
Start a guest with e.g:

  $> qemu-kvm ... -pcidevice host=00:19.0

fails to start with:

  assigned_dev_register_regions: Error: Couldn't mmap 0xffa40000!
  Failed to initialize assigned device host=00:19.0

strace shows:

open("/sys/bus/pci/devices/0000:00:19.0/resource", O_RDONLY) = 11
fstat(11, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8fe2faa000
read(11, "0x00000000ffa40000 0x00000000ffa5ffff 0x0000000000020200\n0x00000000ffa78000 0x00000000ffa78fff 0x0000000000020200\n0x000000000000dc00 0x000000000000dc1f 0x0000000000020101\n0x0000000000000000 0x0000000000000000 0x0000000000000000\n0x0000000000000000 0x00000000"..., 4096) = 399
open("/sys/bus/pci/devices/0000:00:19.0/resource0", O_RDWR) = 12
open("/sys/bus/pci/devices/0000:00:19.0/resource1", O_RDWR) = 13
close(11)                               = 0
munmap(0x7f8fe2faa000, 4096)            = 0
mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_SHARED, 12, 0) = -1 EINVAL (Invalid argument)
write(2, "assigned_dev_register_regions: Error: Couldn't mmap 0xffa40000!\n"...,
Comment 1 Mark McLoughlin 2009-05-06 05:41:42 EDT
Versions involved:

Comment 2 Mark McLoughlin 2009-05-06 06:04:00 EDT
Seems to work if you boot the host with iomem=relaxed
Comment 3 Mark McLoughlin 2009-05-06 06:12:12 EDT
The device in question is:

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
	Subsystem: Intel Corporation Device 0000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 25
	Region 0: Memory at ffa40000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at ffa78000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at dc00 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable+
		Address: 00000000fee0f00c  Data: 41d1
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: e1000e
	Kernel modules: e1000e
Comment 4 Mark McLoughlin 2009-05-06 07:03:40 EDT
Bah, I just got myself confused here.

I was booting the guest with managed='yes', so the device wasn't being detached from its driver and the iomem regions were exclusively owned by the driver, causing the mmap() to fail. Booting with iomem=relaxed just turns off the iomem region checks.
Comment 5 Mark McLoughlin 2009-05-06 10:00:39 EDT
Actually, managed='yes' is correct, except libvirt was interpreting it incorrectly. See bug #499386

Note You need to log in before you can comment on or make changes to this bug.