Bug 499261

Summary: KVM PCI device assignment fails with "assigned_dev_register_regions: Error: Couldn't mmap 0xffa40000!"
Product: [Fedora] Fedora Reporter: Mark McLoughlin <markmc>
Component: qemuAssignee: Mark McLoughlin <markmc>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: high    
Version: rawhideCC: dwmw2, gcosta, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-06 07:03:40 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 480594    

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