On Fri, Feb 25, 2011 at 10:47 PM, James Neave <robo...@gmail.com> wrote: > On Fri, Feb 25, 2011 at 12:06 AM, Chris Wright <chr...@sous-sol.org> wrote: >> * James Neave (robo...@gmail.com) wrote: >>> OK, here's my latest dmesg with amd_iommu_dump and debug with no quiet >>> http://pastebin.com/JxEwvqRA >> >> Yeah, that's what I expected: >> >> [ 0.724403] AMD-Vi: DEV_ALIAS_RANGE devid: 08:00.0 >> flags: 00 devid_to: 00:14.4 >> [ 0.724439] AMD-Vi: DEV_RANGE_END devid: 08:1f.7 >> >> That basically says 08:00.0 - 08:1f.7 will show up as 00:14.4 (and >> should all go into same iommu domain). >> >>> I've just figured out a sequence of "echo DEV > PATH" commands to call >>> for 14.4 gets me past the "claimed by pci-stub" error and gets me to >>> the "failed to assign IRQ" error. >>> I'm going to narrow down the required sequence and then post it. >> >> Kind of afraid to ask, but does it include: >> >> (assuming 1002 4384 is the pci to pci bridge) >> echo 1002 4384 > /sys/bus/pci/drivers/pci-stub/new_id >> echo 0000:00:14.4 > /sys/bus/pci/drivers/pci-stub/unbind >> >> (this has the side effect of detaching the bridge from its domain) >> >> thanks, >> -chris >> > > Exact sequence is: > > echo "1002 4384" > /sys/bus/pci/drivers/pci-stub/new_id > echo "0000:00:14.4" > /sys/bus/pci/devices/0000:00:14.4/driver/unbind > > I take it this is a bad thing then? > >> I assume this means that 00:14.4 is still left claimed by pci-stub? > > Yes > >> How are you determining this? The lspci paste above has pci-stub for all >> of them. The easiest thing might be to start with manually disabling >> host driver and reassigning pci-stub to: 00:14.4, 08: 06.2,3 and 0e.0 >> Then giving the guest only 08:06.1. > > I determined it by being half asleep and not reading it properly... >.< > You're right, all 5 devices were using pci-stub > >>> libvirtError: this function is not supported by the connection driver: >>> Unable to reset PCI device 0000:00:14.4: no FLR, PM reset or bus reset >>> available > >> Right, libvirt is more restrictive than qemu-kvm (forgot you were using >> libvirt here). > > What does that libvirt error mean? I can't find a definition. > Am I limiting myself by using libvirt? Would not using it help and how > would I go about not using it? > >> Trouble now is that >> with shared IRQ we don't have a good way to handle that right now. > > Game over then? > I've tried assigning the USB devices before, I couldn't do it because > qemu doesn't support USB2 devices. > I don't really understand where this IRQ conflict is, the firewire and > the USB2 device share IRQ22 but I'm assigning them both to the VM? > Is that still a problem? > I don't suppose there's any way to change which IRQ they use in the > BIOS or with a command is there? > > I don't know if it means anything but this page: > > http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200 > > Has the lspci output for the HVR-2200 which mentions MSI and IRQ255. > My knowledge it very limited on this subject so I don't know if that's > meaningless looking at the output from another person's lspci. > > Anything left to try? > > Regardless, many thanks for your help, > > James. >
On the off chance I tried disabling the firewire in the BIOS, which leaves only my tuner card using IRQ 20, 21 and 22. No difference, still complains about IRQs: Using raw in/out ioport access (sysfs - Input/output error) Failed to assign irq for "hostdev0": Operation not permitted Perhaps you are assigning a device that shares an IRQ with another device? It does say "Operation not permitted" and that only "perhaps" I am assigning a device that shares an IRQ. Perhaps IRQ conflict it not the problem? They really are sitting on their own. Another permissions problem perhaps? Regards, James. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
