This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Problem passing a HP-DAT (USB) device to domU

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Problem passing a HP-DAT (USB) device to domU
From: Matthias Wolf <matthias.wolf@xxxxxx>
Date: Thu, 23 Aug 2007 19:07:29 +0200
Delivery-date: Thu, 30 Aug 2007 02:56:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2EC81A1.CC19%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Wolf Office Team
References: <C2EC81A1.CC19%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: IceDove (X11/20070606)

thanks a lot for your concern!

Unfortunately, your answer didn't take me too far: At first it was not that easy to find out the vendor:device - combination.

lspci -n


00:1d.7 0c03: 8086:268c (rev 09)

so I assumed 8086:268c was the combination I've been looking for. I edited /etc/xen/xend-pci-permissive.sxp which afterwards looked like this (apart from the comment-lines:


When I bootet the machine hiding LAN-adapters *and* the tapedrive, the network-functionality vanished completely, and no devicefiles for the tape were built in the domU (/dev/*st*).

I tried

lspci --nn --vv -d 8086:268c

to learn that there is a "Subsystem" with an "Unknown device", so I edited /etc/xen/xend-pci-permissive.sxp which then looked like this:


but the result was the same as before: no devicefile for the tapedrive in the domU *and* no networking functionality at all.

This kind of puzzles me, as the respective stanzas in /boot/grub/menu.lst look like this:

title           Xen 3.0.3-1-amd64 / 2.6.18-3-xen-amd64 (LAN & DAT\
root            (hd0,0)
kernel          /xen-3.0.3-1-amd64.gz
module          /vmlinuz-2.6.18-3-xen-amd64\
  root=/dev/mapper/vgraid0-lvroot ro console=tty0\
  pciback.hide=(05:00.0)(05:00.1)(00:1d.7) maxloop=128
module          /initrd.img-2.6.18-3-xen-amd64

title           Xen 3.0.3-1-amd64 / 2.6.18-3-xen-amd64 (LAN hidden)
root            (hd0,0)
kernel /xen-3.0.3-1-amd64.gz module /vmlinuz-2.6.18-3-xen-amd64 root=/dev/mapper/vgraid0-lvroot ro\
  console=tty0 pciback.hide=(05:00.0)(05:00.1) maxloop=128
module          /initrd.img-2.6.18-3-xen-amd64

and I can't spot the difference apart from hiding the tapedrive in the former entry and not doing so in the latter one.

Can anyone help me out? I have to fix this, and I would rather not like to do backups in the dom0, but as it seems at the moment, I'll have to.

Thanks in advance,

greetings from Vienna/Austria

Keir Fraser schrieb:
'lspci -n' to find out what the numeric vendor-id and device-id is for the
device at PCI slot location 00:1d.7. Then add that vendor-id:device-id pair
to /etc/xen/xend-pci-permissive.sxp. When you create the domain that is
assigned the PCI device, you should see a warning appear in dmesg or
/var/log/messages about the fact that a domU is being allowed to write to
any part of a device's PCI config space. You can ignore that, but it shows
that the change to /etc/xen/xend-pci-permissive.sxp is working.

 -- Keir

On 7/8/07 23:28, "Matthias Wolf" <matthias.wolf@xxxxxx> wrote:

Hi specialists,

I'm trying to pass a HP Surestore USB-drive to a domU. I'm hiding the
pci-device in the dom0, capturing it in the domU, and rceive the
following lines in /var/log/syslog of the dom0 after a reboot:

Aug  8 00:04:49 localhost kernel: pciback 0000:00:1d.7: Driver tried to
write to a read-only configuration space field at offset 0x54,
size 2. This may be harmless, but if you have problems with your device:
Aug  8 00:04:49 localhost kernel: 1) see permissive attribute in sysfs
Aug  8 00:04:49 localhost kernel: 2) report problems to the xen-devel
mailing list along with details of your device obtained from lspci.

I'm not quite sure what I'm expected to do in the /sys-tree: root has
write-permissions all the way down the branches.

I'm using the stable version of the xen-hypervisor 3.0.3-0-2 (debian).

I kind of *need* this functionality and would be very grateful for any
kind of help or hint.

Thanx in advance,

Bests from Vienna/Austria
Matthew A. Wolf

pS.: THANKS a whole lot for such a fine piece of software!

Xen-devel mailing list

Xen-devel mailing list