I am trying to get a bt878 capture card working in Ubuntu 7.04 for a video surveillance application running on LAMP stack. It is based on Xen 3.0.3. Got all xm stuff working and apache/mysql/python working in domU. Now need access to /dev/Video0 I first tried pciback, where I get the following failure (from dom0 dmesg). (I blacklisted the bttv and related drivers). [ 0.198929] Kernel command line: root=/dev/md0 ro console=tty0 pciback.permissive pciback.hide=(02:02.0)(02:02.1) [ 0.470768] pciback 0000:02:02.0: seizing device [ 0.470833] pciback 0000:02:02.1: seizing device [ 0.550322] ACPI: PCI Interrupt 0000:02:02.1[A] -> GSI 19 (level, low) -> IRQ 17 [ 0.550452] ACPI: PCI interrupt for device 0000:02:02.1 disabled [ 0.550627] ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 19 (level, low) -> IRQ 17 [ 0.550756] ACPI: PCI interrupt for device 0000:02:02.0 disabled [ 33.929548] pciback: vpci: 0000:02:02.0: assign to virtual slot 0 [ 33.929633] pciback pci-1-0: 22 Couldn''t locate PCI device (0000:02:02.0)! perhaps already in-use? [ 921.917377] ACPI: PCI interrupt for device 0000:02:02.0 disabled So, first off, how can I debug what is failing on the domU handoff? Any way to get more informative dmesg or syslog messages. Are there other logs to look at? Looking at /sys, the 2 devices are linked under the pciback directory. Secondly, thinking that giving a PCI card to the guest is not a good idea, got searching for a way to emulate the device, to preserve Dom0 stability. Ran into the QEMU-DM discussion. So, will this capability be usable on para-virtualized non-VT enabled processors? How do we give users the capability to generically attach devices to Xen guests that do not run the newer processors? John _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Sorry, am not familiar with the current state of PCI passthrough, so I''m going to tackle your second query for now:> Secondly, thinking that giving a PCI card to the guest is not a good > idea, got searching for a way to emulate the device, to preserve Dom0 > stability. Ran into the QEMU-DM discussion. So, will this capability be > usable on para-virtualized non-VT enabled processors? How do we give > users the capability to generically attach devices to Xen guests that do > not run the newer processors?Qemu-dm isn''t (for the moment, anyhow) plumbed through to PV guests. But in any case it only emulates platform hardware and a set of "typical" IO devices, so it wouldn''t be able to pass through random PCI cards... It does offer the potential to pass through individual USB devices to HVM domainsheard good things about how well that works - although maybe things have improved. Right now we''re missing a way to pass through USB devices to PV domains entirely - there was one in tree in the Xen 2.x timeframe, but it suffered from bitrot and was removed. If you have a dedicated PCI card and really want to use Xen then I suspect that the most likely way to do things will be to fiddle with pciback a bit more. Bear in mind that you''re making the domain with the PCI card trusted (potentially as much as dom0 itself) by giving it a PCI device to play with. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote: [snip]> If you have a dedicated PCI card and really want to use Xen then I suspect > that the most likely way to do things will be to fiddle with pciback a bit > more. Bear in mind that you''re making the domain with the PCI card trusted > (potentially as much as dom0 itself) by giving it a PCI device to play with.I have a few questions about pciback.hide, maybe you chaps could give me a clue. For starters, I''m wondering how reliable/stable it is. I''ve had problems which seem to be related to IRQ or DMA not being handled correctly: When a domU accessing a ''hidden'' pci device is shut down sometimes *other* devices in dom0 (ie other than the ''hidden'' one) start having problems. When this includes the hard drive controller one tends to have major issues. Also, with respect to trust of the domU with the PCI device, as I understand it, if the device is already being handled by a driver in the kernel (not a module) then userspace on the domU would not be able to subvert this? I''m thinking that if the device is in use and if it is already handled by an in-kernel driver, then even if an attacker got root on the domU they wouldn''t be able to replace the in-kernel driver with their own and thus not be able to ''break out'' of the domU. This assumes that the domU kernel is not modular and that the kernel file itself is in dom0 not in domU. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:> If you have a dedicated PCI card and really want to use Xen then I suspect > that the most likely way to do things will be to fiddle with pciback a bit > more. Bear in mind that you''re making the domain with the PCI card trusted > (potentially as much as dom0 itself) by giving it a PCI device to play with. > > Cheers, > Mark >Thanks for the reply, Mark... How do I go about debugging the domU handoff. Why does it think that the device is not present. I see it in /sys/bus/pci/drivers/pciback, and I see no bttv or bt878 drivers listed. So I think the blacklisting is working. Is there another log file that I can check, or perhaps is there a set of debug modules that I can install? I noted that this issue came up earlier on the mailing list and no resolution was posted. It may very well be a distinct issue with this type of capture card. John _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users