Problem passing a HP-DAT (USB) device to domU

Problem passing a HP-DAT (USB) device to domU

[Matthias Wolf]

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!

Problem passing a HP-DAT (USB) device to domU

[Matthias Wolf]

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!

Problem passing a HP-DAT (USB) device to domU

[Matthias Wolf]

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!

Re: Problem passing a HP-DAT (USB) device to domU

[Keir Fraser]

'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@wot.at> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Problem passing a HP-DAT (USB) device to domU

[Matthias Wolf]

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@wot.at> 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@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 

Re: Problem passing a HP-DAT (USB) device to domU

[Keir Fraser]

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@wot.at> 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@wot.at> 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@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
>>