Keir,
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
returns
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:
(unconstrained_dev_ids
('8086:268c')
)
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:
(unconstrained_dev_ids
('8086:268c:8086:3484')
)
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\
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)(00:1d.7) maxloop=128
module /initrd.img-2.6.18-3-xen-amd64
savedefault
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
savedefault
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
Matthew
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home