Closing according to comment #3
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/965327
Title:
virtio-pci: can't reserve io 0x-0x001f
Scubbing our ppc64 bugs. Thanks for the update Ken, I'll close this.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/965327
Title:
virtio-pci: can't reserve io 0x-0x001f
Status in QEMU:
New
I'm probably the only person in the world who has this setup (ppc full
emu on win32) but if anyone else out there was following this it was
fixed in qemu.org git and the solution was another __attribute__
((packed)) versus __attribute__ ((gcc_struct, packed)) -mms-bitfield
issue in spapr_pci.c.
Here - http://git.qemu.org/qemu.git - is no mention of 1.1.0-1. The master
branch from there seems
working for me, just checked. Please try the latest master.
This is what my guest prints. Both devices work.
root@erif_root:~# lspci -v
00:00.0 Ethernet controller: Qumranet, Inc. Virtio network
The changelog for 1.1.0-1 states Pseries handles PCI, allowing for
virtio devices with -M pseries while this bug report here still stands
as an issue I'm having where SLOF detects my virtio-block device but
QEMU does not create a virtio-pci device that the Linux kernel can
recognize. I would at
This might be easier to read and understand:
GOOD
Populating /pci@0,0
Adapters on
00 (D) : 1af4 1000 virtio [ net ]
00 0800 (D) : 1af4 1001 virtio [ block ]
...
PCI host bridge /pci@0,0 ranges:
IO
