[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Problem passing a HP-DAT (USB) device to domU
You could try a brute-force test by editing linux/drivers/xen/pciback/conf_space.c and finding the line: if (dev_data->permissive) { And change it to: if (1) { You can then put xend-pci-permissive.sxp back as it was. This should allow any PCI config accesses by your domU driver domain to succeed. -- Keir On 23/8/07 18:07, "Matthias Wolf" <matthias.wolf@xxxxxx> wrote: > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |