Bug 582752 - decimal/hex confusion when adding pci devices to a vm
Summary: decimal/hex confusion when adding pci devices to a vm
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 596473 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-15 18:02 UTC by Gerd v. Egidy
Modified: 2010-05-28 17:58 UTC (History)
9 users (show)

Fixed In Version: libvirt-0.7.7-4.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-28 17:58:48 UTC


Attachments (Terms of Use)
Device list as shown by add pci device wizard (77.63 KB, image/png)
2010-04-15 18:02 UTC, Gerd v. Egidy
no flags Details

Description Gerd v. Egidy 2010-04-15 18:02:18 UTC
Created attachment 406874 [details]
Device list as shown by add pci device wizard

Description of problem:
When adding a pci device to a libvirt-managed vm via virt-manager, the wrong pci id is configured in libvirt.

Version-Release number of selected component (if applicable):
virt-manager-0.8.3-2.fc13.noarch
libvirt-0.7.7-1.fc13.x86_64

How reproducible:
always for device-ids matching some yet unknown criteria (probably some value >= 0x10)

Steps to Reproduce:
1. create a vm using qemu-kvm
2. add a pci device vm with virt-manager. It seems like the slot of the pci id must be lager than 0x10 to trigger the bug. I selected pci id "01:10:1" to reproduce it (see screenshot). The list of ids shown by virt-manager matches the output of lspci
  
Actual results:
virt-manager tells libvirt to add the device, but confuses the slot data. This is what gets written to the libvirt-xml:

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x01' slot='0x16' function='0x1'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</hostdev>

So to me it seems like virt-manager writes 0x10 or 16 decimal to libvirt, but libvirt treats it as 16 hex.

Expected results:

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x01' slot='0x10' function='0x1'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</hostdev>

Comment 1 Cole Robinson 2010-05-06 18:54:53 UTC
This is a libvirt issue, now fixed upstream. Should be a simple backport:

http://libvirt.org/git/?p=libvirt.git;a=commit;h=e984019688509605966c03cd77f4591d2cc222d3

Comment 2 Gerd v. Egidy 2010-05-13 21:12:04 UTC
I can confirm that this issue is fixed with current libvirt git.

Now we only need a backport of the patch into F13 or (even better) an upgrade to current libvirt.

Comment 3 Fedora Update System 2010-05-18 19:02:41 UTC
libvirt-0.7.7-4.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libvirt-0.7.7-4.fc13

Comment 4 Fedora Update System 2010-05-19 19:14:19 UTC
libvirt-0.7.7-4.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libvirt'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libvirt-0.7.7-4.fc13

Comment 5 Cole Robinson 2010-05-26 19:38:25 UTC
*** Bug 596473 has been marked as a duplicate of this bug. ***

Comment 6 Fedora Update System 2010-05-28 17:58:24 UTC
libvirt-0.7.7-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


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