Bug 499261 - KVM PCI device assignment fails with "assigned_dev_register_regions: Error: Couldn't mmap 0xffa40000!"
Summary: KVM PCI device assignment fails with "assigned_dev_register_regions: Error: C...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: rawhide
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Mark McLoughlin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F11VirtTarget
TreeView+ depends on / blocked
 
Reported: 2009-05-05 20:48 UTC by Mark McLoughlin
Modified: 2009-05-06 14:00 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-05-06 11:03:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mark McLoughlin 2009-05-05 20:48:44 UTC
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 09:41:42 UTC
Versions involved:

qemu-system-x86-0.10-16.fc11.x86_64
kernel-2.6.29.2-126.fc11.x86_64

Comment 2 Mark McLoughlin 2009-05-06 10:04:00 UTC
Seems to work if you boot the host with iomem=relaxed

Comment 3 Mark McLoughlin 2009-05-06 10:12:12 UTC
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 11:03:40 UTC
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 14:00:39 UTC
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.