I asked this question on the users list a few days ago, but got no
response, perhaps it's a bit too involved for that list, I hope it's not
*too* unwelcome here ...
I'm trying to use PCI passthrough of a DVB-T tuner from a fedora8 dom0,
to a centOS5.2 domU
On the dom0 I have the following kernel/xen installed
On the domU I have the following kernel installed
Additionally I had to manually compile the saa7134_dvb.ko module for the
digital section of the card as the centosplus kernel only had the
saa7134.ko module for the analogue section of the card.
I tried adding a pciback.hide entry to grub.conf for the dom0, but this
wasn't recognised, presumably because pciback is compiled as a module on
fedora8 dom0 kernel?
I realise I can add entries to modprobe.conf to ensure no dom0 drivers
bind to my device, but for now I'm using the following script to get
dom0 to relinquish the card and make it available for the domU.
echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
I then create my domU with this config file
memory = 1024
name = "mythbe"
vif = [ 'mac=00:16:3E:76:E8:92, bridge=eth0' ]
disk = [ 'phy:/dev/vgr1/lvmythroot,xvda,w',
pci = ['08:01.0']
bootloader = "/usr/bin/pygrub"
vcpus = 1
on_reboot = 'restart'
on_crash = 'restart'
I see a few PCI related messages in the domU dmesg
PCI: Fatal: No PCI config space access function found
PCI: setting up Xen PCI frontend stub
PCI: System does not support PCI
PCI: System does not support PCI
pcifront pci-0: Installing PCI frontend
pcifront pci-0: Creating PCI Frontend Bus 0000:00
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
PCI: Enabling device 0000:00:00.0 (0000 -> 0002)
The DVB-T card is visble in the domU
# lspci -v
00:00.0 Multimedia controller: Philips Semiconductors SAA7130 Video
Broadcast Decoder (rev 01)
Subsystem: Compro Technology, Inc. Videomate DVB-T200
Flags: bus master, medium devsel, latency 64, IRQ 17
Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities:  Power Management version 1
I assume it's normal that the PCI bus/device/function numbers have been
changed between dom0 and domU?
The driver modules are being loaded by the domU
# lsmod | grep saa
saa7134_dvb 48004 0
dvb_pll 48965 1 saa7134_dvb
mt352 40133 1 saa7134_dvb
video_buf_dvb 40133 1 saa7134_dvb
nxt200x 46661 1 saa7134_dvb
tda1004x 48581 1 saa7134_dvb
saa7134 159017 1 saa7134_dvb
video_buf 59717 3 saa7134_dvb,video_buf_dvb,saa7134
compat_ioctl32 41793 1 saa7134
ir_kbd_i2c 42961 1 saa7134
i2c_core 56129 7
ir_common 63173 2 saa7134,ir_kbd_i2c
videodev 58049 1 saa7134
v4l1_compat 44613 2 saa7134,videodev
v4l2_common 57153 3 saa7134,compat_ioctl32,videodev
I see an error in dmesg on the domU
# dmesg | grep -i saa
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7130: found at 0000:00:00.0, rev: 1, irq: 17, latency: 64, mmio:
saa7130: subsystem: 185b:c901, board: Compro Videomate DVB-T200
saa7130: can't ioremap() MMIO memory
saa7134: probe of 0000:00:00.0 failed with error -5
The calling code in domU is here
I also receive a corresponding message in dom0
# xm dmesg
(XEN) mm.c:625:d6 Non-privileged (6) attempt to map I/O space 000fec00
The called code in dom0 is here
Am I right in thinking the pciback.permissive parameter is now removed?
Certainly modinfo is unaware of it.
Any suggestions for how to stop the ioremap() call from failing and thus
allow the driver to loading properly?
Xen-devel mailing list