On Thu, 2015-10-01 at 22:38 -0400, Phil (list) wrote: > On Thu, 2015-10-01 at 08:32 -0400, Mauricio Tavares wrote: > > On Thu, Oct 1, 2015 at 3:27 AM, Phil (list) <pbpublist@xxxxxxxxx> > > wrote: > > > If this isn't the right place to ask, any pointers to the correct > > > place > > > are appreciated... > > > > > > I'm trying to see if I can get PCI passthrough working for a video > > > capture card (Hauppauge Colossus 1x PCIe) under a Windows XP guest > > > (32 > > > -bit). Things appear to be somewhat working (Windows is seeing the > > > device, the drivers successfully installed, and device manager > > > indicates everything is working) however when I fire up the capture > > > application, it is not able to find the device despite Windows > > > recognizing it (no errors, it just doesn't 'see' any installed > > > capture > > > devices). There is also a secondary capture/viewer application > > > that > > > won't even install due to not being able to find a capture card. > > > Since > > > that wasn't the behavior when running it natively under Windows, > > > I'm > > > assuming that the issue is related to PCI passthrough but it's > > > difficult to be certain since I'm not seeing any errors beyond the > > > capture applications not being able to find the device. > > > > > I think you need to find out if the problem follows the > > program, > > the card, or the passthrough thingie. For instance, is there any > > other > > program you can run to see if it sees the card? If you can't think of > > anything, you could run a, say, ubuntu/fedora livecd (start you vm > > client and tell it to boot from iso) and see if it can see and use > > the > > card. > > > > I only have the two capture apps that came with the card as I don't > really use Windows for much other than this card anymore. > > To try to verify that everything is fine from a hardware / Windows > driver standpoint: I took a spare drive and performed a bare metal Win > XP install, installed the drivers, and then the capture software (i.e. > the same sequence and software versions as I used in the VM) and > everything works properly (i.e. both capture applications were able to > detect and use the capture card as expected). Other than using a > different hard drive, all other system hardware was identical. So that > would seem to rule out everything from the hardware through to the > Windows applications and leave it back in the realm of kvm/PCI > passthrough. > > Unfortunately, no Linux drivers exist for this card (i.e. the reason > I'm attempting to use it under Windows in a VM) so any other Linux > distro would have about the same level of support in that it would > recognize that the PCI card exists but then not be able to do anything > with it. If you're thinking that there is a problem with version of > kvm in Debian, I would be open to trying another distro if that would > help troubleshoot it. I'm also reasonably comfortable navigating > around kvm, it's the PCI passthrough functionality that is new to me. Are you using vfio to do the device assignment or legacy KVM device assignment. If the latter, try the former. Since you're using a 32-bit Windows guest, what CPU model are you exposing to the VM? Windows can be rather particular about enabling MSI for devices if the processor model seen by the VM is too old (does the device support MSI?). '-cpu host' might help or "host-passthrough" if using libvirt. You can look in /proc/interrupts on the host and see if you're getting interrupts (non-zero count on at least one of the CPUs for the interrupt associated with the device). If instead the device is using INTx interrupts, interrupt masking might be broken. You can try using the nointxmask=1 module option to vfio-pci, for force masking at the APIC rather than the device, but be forewarned that you'll need to make the interrupt for the device exclusive, either by locating it in a slot where it won't share interrupts or unloading drivers from devices sharing the interrupt line. There's always the chance that the device is simply not compatible with PCI device assignment. We do rely on some degree of good behavior on the part of the device. Some environments also expect to find the device behind a PCIe root port, which is not the topology we expose on the default 440fx VM chipset. It's possible that such devices might work on the Q35 chipset or by placing the device behind a pci-bridge to fool the software. It's really hard to tell what might be wrong, especially since the driver appears to work and only the application fails, and it's all proprietary code within the black box of a VM. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
