Xen devel - May 2013 - PCI passthrough problems after legacy update of xen 4.1

Hi,

My ubuntu 12.10 vanilla install (amd64) recently got xen hypervisor and
utils upgraded to 4.1.3-3ubuntu1.5, via the legacy upgrade path. After this
I experience problems with passing through some PCI devices to a windows 8
domU. I get the same problem as Gordan gets with 4.2 referred in this
message: http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html-
it seems to be related to some update made to both trees.

My symptom is that out of three devices/functions, a radeon 7790 with its
two functions (41:00.{01}) plus one TI usb controller, (04:00.0), only the
radeon gpu (41:00.0) gets passed through. The others fail with the Error:
(22, ''Invalid argument'') message. Specifically:

When passing the usb controller (04:00.0) only, I find the following in
xend.log:

[2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:815) pci: assign device
0000:04:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-01 10:38:32 2568] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-01 10:38:32 2568] INFO (pciquirk:92) NO quirks found for PCI
device [104c:8241:0000:0000]
[2013-05-01 10:38:32 2568] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [104c:8241:0000:0000]
[2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
0xdfef0000/0x10000 pfn 0xdfef0/0x10
[2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
0xdfeee000/0x2000 pfn 0xdfeee/0x2
[2013-05-01 10:38:32 2568] DEBUG (pciif:351) pci: enabling irq 19
[2013-05-01 10:38:32 2568] ERROR (XendDomainInfo:2927)
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2914, in _initDomain
    self._createDevices()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2395, in _createDevices
    self.pci_device_configure_boot()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 627, in pci_device_configure_boot
    self.pci_device_configure(dev_sxp, first_dev = first)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 970, in pci_device_configure
    devid = self._createDevice(''pci'', existing_pci_conf)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2326, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
67, in createDevice
    self.setupDevice(config)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
453, in setupDevice
    self.setupOneDevice(d)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
353, in setupOneDevice
    allow_access = True)
Error: (22, ''Invalid argument'')

Interestingly, if I try to pass through only the GPU only (41:00.0) it does
work, but with both functions of the radeon card passed it fails again. As
said, it fails also if I only pass the USB controller, so it''s not
really
VGA related. I can provide more log output if needed.

According to various sources on the net, downgrading xen would solve the
problem. But I''d prefer to raise the issue and find out if it is a xen
bug
or a hardware specification issue.

Regards,
Andreas


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

This is probably worthy of a bug report escalation to xen-devel list.

 I have filed my logs via the EL6 Xen bug tracker here:

 http://xen.crc.id.au/bugs/view.php?id=5

 It is good to see that it is not specific to the package builds/distro,
 in the sense that it implies a real, reproducible bug that might
 actually get fixed. I narrowed the cause down to a particular patch.
 (see link above).

 Gordan

 On Wed, 1 May 2013 10:56:05 +0200, Andreas Falck 
 <falck.andreas.lists@gmail.com> wrote:
> Hi,
>
> My ubuntu 12.10 vanilla install (amd64) recently got xen hypervisor
> and utils upgraded to 4.1.3-3ubuntu1.5, via the legacy upgrade path.
> After this I experience problems with passing through some PCI 
> devices
> to a windows 8 domU. I get the same problem as Gordan gets with 4.2
> referred in this message:
> http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html 
> [1]
> - it seems to be related to some update made to both trees.
>
> My symptom is that out of three devices/functions, a radeon 7790 with
> its two functions (41:00.{01}) plus one TI usb controller, (04:00.0),
> only the radeon gpu (41:00.0) gets passed through. The others fail
> with the Error: (22, 'Invalid argument') message. Specifically:
>
> When passing the usb controller (04:00.0) only, I find the following
> in xend.log:
>
> [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:811)
> XendDomainInfo.hvm_pci_device_insert_dev:
> 0000:04:00.0@100,msitranslate=1,power_mgmt=1
>  [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:815) pci: assign
> device 0000:04:00.0@100,msitranslate=1,power_mgmt=1
> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
>  [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
> [2013-05-01 10:38:32 2568] INFO (image:538) signalDeviceModel:restore
> dm state to running
>  [2013-05-01 10:38:32 2568] INFO (pciquirk:92) NO quirks found for 
> PCI
> device [104c:8241:0000:0000]
> [2013-05-01 10:38:32 2568] DEBUG (pciquirk:135) Permissive mode NOT
> enabled for PCI device [104c:8241:0000:0000]
> [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
> 0xdfef0000/0x10000 pfn 0xdfef0/0x10
>  [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
> 0xdfeee000/0x2000 pfn 0xdfeee/0x2
> [2013-05-01 10:38:32 2568] DEBUG (pciif:351) pci: enabling irq 19
> [2013-05-01 10:38:32 2568] ERROR (XendDomainInfo:2927)
> XendDomainInfo.initDomain: exception occurred
>  Traceback (most recent call last):
>   File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line
> 2914, in _initDomain
>     self._createDevices()
>   File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line
> 2395, in _createDevices
>      self.pci_device_configure_boot()
>   File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line
> 627, in pci_device_configure_boot
>     self.pci_device_configure(dev_sxp, first_dev = first)
>    File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line
> 970, in pci_device_configure
>     devid = self._createDevice('pci', existing_pci_conf)
>   File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line
> 2326, in _createDevice
>      return
> self.getDeviceController(deviceClass).createDevice(devConfig)
>   File
> 
>
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
> line 67, in createDevice
>     self.setupDevice(config)
>    File
> "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
> 453, in setupDevice
>     self.setupOneDevice(d)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
> line 353, in setupOneDevice
>      allow_access = True)
> Error: (22, 'Invalid argument')
>
> Interestingly, if I try to pass through only the GPU only (41:00.0) 
> it
> does work, but with both functions of the radeon card passed it fails
> again. As said, it fails also if I only pass the USB controller, so
> it's not really VGA related. I can provide more log output if needed.
>
> According to various sources on the net, downgrading xen would solve
> the problem. But I'd prefer to raise the issue and find out if it is 
> a
> xen bug or a hardware specification issue.
>
> Regards,
>  Andreas
>
>
> Links:
> ------
> [1] 
> http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

I CC the xen-devel list, since that is where I understand that possible
bugs in the main xen tree should be reported. My initial description of the
problem is attached below.

I tried with and without global interrupt remapping
(iommu=amd-iommu-global-intremap in xen command line), the problem
persists. That was after reading this:
http://www.novell.com/support/kb/doc.php?id=7012337

I can provide more information from my system if needed.

Regards,
Andreas


2013/5/1 Gordan Bobic <gordan@bobich.net>
> This is probably worthy of a bug report escalation to xen-devel list.
>
> I have filed my logs via the EL6 Xen bug tracker here:
>
>
http://xen.crc.id.au/bugs/**view.php?id=5<http://xen.crc.id.au/bugs/view.php?id=5>
>
> It is good to see that it is not specific to the package builds/distro,
> in the sense that it implies a real, reproducible bug that might
> actually get fixed. I narrowed the cause down to a particular patch.
> (see link above).
>
> Gordan
>
>
> On Wed, 1 May 2013 10:56:05 +0200, Andreas Falck <
> falck.andreas.lists@gmail.com**> wrote:
>
>> Hi,
>>
>> My ubuntu 12.10 vanilla install (amd64) recently got xen hypervisor
>> and utils upgraded to 4.1.3-3ubuntu1.5, via the legacy upgrade path.
>> After this I experience problems with passing through some PCI devices
>> to a windows 8 domU. I get the same problem as Gordan gets with 4.2
>> referred in this message:
>>
http://lists.xen.org/archives/**html/xen-users/2013-04/**msg00341.html<http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html>[1]
>>
>> - it seems to be related to some update made to both trees.
>>
>> My symptom is that out of three devices/functions, a radeon 7790 with
>> its two functions (41:00.{01}) plus one TI usb controller, (04:00.0),
>> only the radeon gpu (41:00.0) gets passed through. The others fail
>> with the Error: (22, ''Invalid argument'') message.
Specifically:
>>
>> When passing the usb controller (04:00.0) only, I find the following
>> in xend.log:
>>
>> [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:811)
>> XendDomainInfo.hvm_pci_device_**insert_dev:
>> 0000:04:00.0@100,msitranslate=**1,power_mgmt=1
>>  [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:815) pci: assign
>> device 0000:04:00.0@100,msitranslate=**1,power_mgmt=1
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>>  [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] INFO (image:538) signalDeviceModel:restore
>> dm state to running
>>  [2013-05-01 10:38:32 2568] INFO (pciquirk:92) NO quirks found for PCI
>> device [104c:8241:0000:0000]
>> [2013-05-01 10:38:32 2568] DEBUG (pciquirk:135) Permissive mode NOT
>> enabled for PCI device [104c:8241:0000:0000]
>> [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
>> 0xdfef0000/0x10000 pfn 0xdfef0/0x10
>>  [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
>> 0xdfeee000/0x2000 pfn 0xdfeee/0x2
>> [2013-05-01 10:38:32 2568] DEBUG (pciif:351) pci: enabling irq 19
>> [2013-05-01 10:38:32 2568] ERROR (XendDomainInfo:2927)
>> XendDomainInfo.initDomain: exception occurred
>>  Traceback (most recent call last):
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2914, in _initDomain
>>     self._createDevices()
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2395, in _createDevices
>>      self.pci_device_configure_**boot()
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 627, in pci_device_configure_boot
>>     self.pci_device_configure(dev_**sxp, first_dev = first)
>>    File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 970, in pci_device_configure
>>     devid = self._createDevice(''pci'',
existing_pci_conf)
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2326, in _createDevice
>>      return
>> self.getDeviceController(**deviceClass).createDevice(**devConfig)
>>   File
>>
>> "/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/**
>> DevController.py",
>> line 67, in createDevice
>>     self.setupDevice(config)
>>    File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/pciif.**py",
line
>> 453, in setupDevice
>>     self.setupOneDevice(d)
>>   File
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/pciif.**py",
>> line 353, in setupOneDevice
>>      allow_access = True)
>> Error: (22, ''Invalid argument'')
>>
>> Interestingly, if I try to pass through only the GPU only (41:00.0) it
>> does work, but with both functions of the radeon card passed it fails
>> again. As said, it fails also if I only pass the USB controller, so
>> it''s not really VGA related. I can provide more log output if
needed.
>>
>> According to various sources on the net, downgrading xen would solve
>> the problem. But I''d prefer to raise the issue and find out if
it is a
>> xen bug or a hardware specification issue.
>>
>> Regards,
>>  Andreas
>>
>>
>> Links:
>> ------
>> [1] http://lists.xen.org/archives/**html/xen-users/2013-04/**
>>
msg00341.html<http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html>
>>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

I CC the xen-devel list, since that is where I understand that possible
bugs in the main xen tree should be reported. My initial description of the
problem is attached below.

I tried with and without global interrupt remapping
(iommu=amd-iommu-global-intremap in xen command line), the problem
persists. That was after reading this:
http://www.novell.com/support/kb/doc.php?id=7012337

I can provide more information from my system if needed.

Regards,
Andreas


2013/5/1 Gordan Bobic <gordan@bobich.net>
> This is probably worthy of a bug report escalation to xen-devel list.
>
> I have filed my logs via the EL6 Xen bug tracker here:
>
>
http://xen.crc.id.au/bugs/**view.php?id=5<http://xen.crc.id.au/bugs/view.php?id=5>
>
> It is good to see that it is not specific to the package builds/distro,
> in the sense that it implies a real, reproducible bug that might
> actually get fixed. I narrowed the cause down to a particular patch.
> (see link above).
>
> Gordan
>
>
> On Wed, 1 May 2013 10:56:05 +0200, Andreas Falck <
> falck.andreas.lists@gmail.com**> wrote:
>
>> Hi,
>>
>> My ubuntu 12.10 vanilla install (amd64) recently got xen hypervisor
>> and utils upgraded to 4.1.3-3ubuntu1.5, via the legacy upgrade path.
>> After this I experience problems with passing through some PCI devices
>> to a windows 8 domU. I get the same problem as Gordan gets with 4.2
>> referred in this message:
>>
http://lists.xen.org/archives/**html/xen-users/2013-04/**msg00341.html<http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html>[1]
>>
>> - it seems to be related to some update made to both trees.
>>
>> My symptom is that out of three devices/functions, a radeon 7790 with
>> its two functions (41:00.{01}) plus one TI usb controller, (04:00.0),
>> only the radeon gpu (41:00.0) gets passed through. The others fail
>> with the Error: (22, ''Invalid argument'') message.
Specifically:
>>
>> When passing the usb controller (04:00.0) only, I find the following
>> in xend.log:
>>
>> [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:811)
>> XendDomainInfo.hvm_pci_device_**insert_dev:
>> 0000:04:00.0@100,msitranslate=**1,power_mgmt=1
>>  [2013-05-01 10:38:32 2568] DEBUG (XendDomainInfo:815) pci: assign
>> device 0000:04:00.0@100,msitranslate=**1,power_mgmt=1
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>>  [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] DEBUG (image:508) signalDeviceModel:
>> orig_state is None, retrying
>> [2013-05-01 10:38:32 2568] INFO (image:538) signalDeviceModel:restore
>> dm state to running
>>  [2013-05-01 10:38:32 2568] INFO (pciquirk:92) NO quirks found for PCI
>> device [104c:8241:0000:0000]
>> [2013-05-01 10:38:32 2568] DEBUG (pciquirk:135) Permissive mode NOT
>> enabled for PCI device [104c:8241:0000:0000]
>> [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
>> 0xdfef0000/0x10000 pfn 0xdfef0/0x10
>>  [2013-05-01 10:38:32 2568] DEBUG (pciif:334) pci: enabling iomem
>> 0xdfeee000/0x2000 pfn 0xdfeee/0x2
>> [2013-05-01 10:38:32 2568] DEBUG (pciif:351) pci: enabling irq 19
>> [2013-05-01 10:38:32 2568] ERROR (XendDomainInfo:2927)
>> XendDomainInfo.initDomain: exception occurred
>>  Traceback (most recent call last):
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2914, in _initDomain
>>     self._createDevices()
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2395, in _createDevices
>>      self.pci_device_configure_**boot()
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 627, in pci_device_configure_boot
>>     self.pci_device_configure(dev_**sxp, first_dev = first)
>>    File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 970, in pci_device_configure
>>     devid = self._createDevice(''pci'',
existing_pci_conf)
>>   File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/**XendDomainInfo.py",
line
>> 2326, in _createDevice
>>      return
>> self.getDeviceController(**deviceClass).createDevice(**devConfig)
>>   File
>>
>> "/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/**
>> DevController.py",
>> line 67, in createDevice
>>     self.setupDevice(config)
>>    File
>>
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/pciif.**py",
line
>> 453, in setupDevice
>>     self.setupOneDevice(d)
>>   File
"/usr/lib/xen-4.1/bin/../lib/**python/xen/xend/server/pciif.**py",
>> line 353, in setupOneDevice
>>      allow_access = True)
>> Error: (22, ''Invalid argument'')
>>
>> Interestingly, if I try to pass through only the GPU only (41:00.0) it
>> does work, but with both functions of the radeon card passed it fails
>> again. As said, it fails also if I only pass the USB controller, so
>> it''s not really VGA related. I can provide more log output if
needed.
>>
>> According to various sources on the net, downgrading xen would solve
>> the problem. But I''d prefer to raise the issue and find out if
it is a
>> xen bug or a hardware specification issue.
>>
>> Regards,
>>  Andreas
>>
>>
>> Links:
>> ------
>> [1] http://lists.xen.org/archives/**html/xen-users/2013-04/**
>>
msg00341.html<http://lists.xen.org/archives/html/xen-users/2013-04/msg00341.html>
>>
>
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

>>> On 01.05.13 at 16:22, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> I CC the xen-devel list, since that is where I understand that possible
> bugs in the main xen tree should be reported. My initial description of the
> problem is attached below.
> 
> I tried with and without global interrupt remapping
> (iommu=amd-iommu-global-intremap in xen command line), the problem
> persists. That was after reading this:
> http://www.novell.com/support/kb/doc.php?id=7012337 
> 
> I can provide more information from my system if needed.
If you could just try out the tentative solution described in
http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
that would already help.

Jan

>>> On 01.05.13 at 16:22, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> I CC the xen-devel list, since that is where I understand that possible
> bugs in the main xen tree should be reported. My initial description of the
> problem is attached below.
> 
> I tried with and without global interrupt remapping
> (iommu=amd-iommu-global-intremap in xen command line), the problem
> persists. That was after reading this:
> http://www.novell.com/support/kb/doc.php?id=7012337 
> 
> I can provide more information from my system if needed.
If you could just try out the tentative solution described in
http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
that would already help.

Jan

2013/5/2 Jan Beulich <JBeulich@suse.com>
>
> If you could just try out the tentative solution described in
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
> that would already help.
>
I will have a look when I come home from work, it will be a few hours from
now. Just so that I understand it right, is this simply a matter of editing
pciif.py and commenting out the line

        if not self.vm.info.is_hvm() and dev.irq:

so that the conditioned code is executed for all guests?

Regards,
Andreas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

2013/5/2 Jan Beulich <JBeulich@suse.com>
>
> If you could just try out the tentative solution described in
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
> that would already help.
>
I will have a look when I come home from work, it will be a few hours from
now. Just so that I understand it right, is this simply a matter of editing
pciif.py and commenting out the line

        if not self.vm.info.is_hvm() and dev.irq:

so that the conditioned code is executed for all guests?

Regards,
Andreas


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

>>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> 2013/5/2 Jan Beulich <JBeulich@suse.com>
> 
>>
>> If you could just try out the tentative solution described in
>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html 
>> that would already help.
>>
> 
> I will have a look when I come home from work, it will be a few hours from
> now. Just so that I understand it right, is this simply a matter of editing
> pciif.py and commenting out the line
> 
>         if not self.vm.info.is_hvm() and dev.irq:
> 
> so that the conditioned code is executed for all guests?
No, not the entire line, just the is_hvm part needs to be dropped.

Jan

>>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> 2013/5/2 Jan Beulich <JBeulich@suse.com>
> 
>>
>> If you could just try out the tentative solution described in
>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html 
>> that would already help.
>>
> 
> I will have a look when I come home from work, it will be a few hours from
> now. Just so that I understand it right, is this simply a matter of editing
> pciif.py and commenting out the line
> 
>         if not self.vm.info.is_hvm() and dev.irq:
> 
> so that the conditioned code is executed for all guests?
No, not the entire line, just the is_hvm part needs to be dropped.

Jan

Ok, I changed so that the corresponding first lines of code looks like this:

        if dev.irq:
            rc = xc.physdev_map_pirq(domid = fe_domid,
                                   index = dev.irq,
                                   pirq  = dev.irq)

(only the first line changed)
Then, after restarting xend, I get a different failure on line 346, which
is the last line of the above: "VmError: (17, ''File
exists'')". Full
xend.log attached below.

I can also do tests with the one device which I still manage to pass
through (a gpu), if I get specific suggestions on what to look for.

/Andreas

[2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:815) pci: assign device
0000:04:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 20:41:29 19545] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 20:41:29 19545] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 20:41:30 19545] INFO (pciquirk:92) NO quirks found for PCI
device [104c:8241:0000:0000]
[2013-05-02 20:41:30 19545] DEBUG (pciquirk:135) Permissive mode NOT
enabled for PCI device [104c:8241:0000:0000]
[2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
0xdfef0000/0x10000 pfn 0xdfef0/0x10
[2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
0xdfeee000/0x2000 pfn 0xdfeee/0x2
[2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:2927)
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2914, in _initDomain
    self._createDevices()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2395, in _createDevices
    self.pci_device_configure_boot()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 627, in pci_device_configure_boot
    self.pci_device_configure(dev_sxp, first_dev = first)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 970, in pci_device_configure
    devid = self._createDevice(''pci'', existing_pci_conf)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2326, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
67, in createDevice
    self.setupDevice(config)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
453, in setupDevice
    self.setupOneDevice(d)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
346, in setupOneDevice
    pirq  = dev.irq)
Error: (17, ''File exists'')
[2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (17, ''File exists'')
[2013-05-02 20:41:30 19545] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=19
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2401) Destroying device
model
[2013-05-02 20:41:32 19545] INFO (image:615) w8 device model terminated
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vfb/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2406) No device model
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 20:41:32 19545] ERROR (XendDomainInfo:108) Domain construction
failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 106, in create
    vm.start()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (17, ''File exists'')



2013/5/2 Jan Beulich <JBeulich@suse.com>
> >>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com>
> wrote:
> > 2013/5/2 Jan Beulich <JBeulich@suse.com>
> >
> >>
> >> If you could just try out the tentative solution described in
> >> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
> >> that would already help.
> >>
> >
> > I will have a look when I come home from work, it will be a few hours
> from
> > now. Just so that I understand it right, is this simply a matter of
> editing
> > pciif.py and commenting out the line
> >
> >         if not self.vm.info.is_hvm() and dev.irq:
> >
> > so that the conditioned code is executed for all guests?
>
> No, not the entire line, just the is_hvm part needs to be dropped.
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Ok, I changed so that the corresponding first lines of code looks like this:

        if dev.irq:
            rc = xc.physdev_map_pirq(domid = fe_domid,
                                   index = dev.irq,
                                   pirq  = dev.irq)

(only the first line changed)
Then, after restarting xend, I get a different failure on line 346, which
is the last line of the above: "VmError: (17, ''File
exists'')". Full
xend.log attached below.

I can also do tests with the one device which I still manage to pass
through (a gpu), if I get specific suggestions on what to look for.

/Andreas

[2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:815) pci: assign device
0000:04:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 20:41:29 19545] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 20:41:29 19545] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 20:41:30 19545] INFO (pciquirk:92) NO quirks found for PCI
device [104c:8241:0000:0000]
[2013-05-02 20:41:30 19545] DEBUG (pciquirk:135) Permissive mode NOT
enabled for PCI device [104c:8241:0000:0000]
[2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
0xdfef0000/0x10000 pfn 0xdfef0/0x10
[2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
0xdfeee000/0x2000 pfn 0xdfeee/0x2
[2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:2927)
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2914, in _initDomain
    self._createDevices()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2395, in _createDevices
    self.pci_device_configure_boot()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 627, in pci_device_configure_boot
    self.pci_device_configure(dev_sxp, first_dev = first)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 970, in pci_device_configure
    devid = self._createDevice(''pci'', existing_pci_conf)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2326, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
67, in createDevice
    self.setupDevice(config)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
453, in setupDevice
    self.setupOneDevice(d)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
346, in setupOneDevice
    pirq  = dev.irq)
Error: (17, ''File exists'')
[2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (17, ''File exists'')
[2013-05-02 20:41:30 19545] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=19
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2401) Destroying device
model
[2013-05-02 20:41:32 19545] INFO (image:615) w8 device model terminated
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vfb/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2406) No device model
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 20:41:32 19545] ERROR (XendDomainInfo:108) Domain construction
failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 106, in create
    vm.start()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (17, ''File exists'')



2013/5/2 Jan Beulich <JBeulich@suse.com>
> >>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com>
> wrote:
> > 2013/5/2 Jan Beulich <JBeulich@suse.com>
> >
> >>
> >> If you could just try out the tentative solution described in
> >> http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
> >> that would already help.
> >>
> >
> > I will have a look when I come home from work, it will be a few hours
> from
> > now. Just so that I understand it right, is this simply a matter of
> editing
> > pciif.py and commenting out the line
> >
> >         if not self.vm.info.is_hvm() and dev.irq:
> >
> > so that the conditioned code is executed for all guests?
>
> No, not the entire line, just the is_hvm part needs to be dropped.
>
> Jan
>
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Ok, I have some progress. It tried also with the device I had always
managed to get through, the radeon 7790 gpu. This worked equally well with
both versions of pciif.py. However, it turned out that with the changed
version, if I pass the gpu first in the pci = [ ... ] list, the other
devices also gets through. This was not the case with the original version
of pciif.py.

If (and only if) i order the passthrough list in the config file so that it
says

pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]

(This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) - then
passthrough of all devices works with the new version of pciif.py ("if
dev.irq:"), but not with the old version ("if not
self.vm.info.is_hvm() and
dev.irq:"). So the second failure seemingly has to do with some property
set or checked only for the first passed through device. Logs follow:

WORKING setup:
pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]
NEW pciif.py (if dev.irq)

xend.log:
[2013-05-02 22:54:38 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:41:00.0.
[2013-05-02 22:54:38 7863] INFO (pciquirk:92) NO quirks found for PCI
device [1002:665c:1458:2269]
[2013-05-02 22:54:38 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:665c:1458:2269]
[2013-05-02 22:54:38 7863] DEBUG (pciif:320) pci: enabling ioport
0xe000/0x100
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xa0000000/0x10000000 pfn 0xa0000/0x10000
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0x9f800000/0x800000 pfn 0x9f800/0x800
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xbffc0000/0x40000 pfn 0xbffc0/0x40
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xbffa0000/0x20000 pfn 0xbffa0/0x20
[2013-05-02 22:54:38 7863] DEBUG (pciif:351) pci: enabling irq 16
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:893)
XendDomainInfo.pci_device_configure: [''pci'',
[''dev'', [''slot'', ''0x00''],
[''domain'', ''0x0000''],
[''key'', ''41:00.1''],
[''bus'', ''0x41''],
[''vdevfn'',
''0x100''], [''func'', ''0x1''],
[''uuid'',
''e94457db-ac50-04a3-216f-9fb6c8aab1f1'']],
[''state'', ''Initialising''],
[''sub_state'', ''Booting'']]
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:779)
XendDomainInfo.hvm_pci_device_insert: {''devs'':
[{''slot'': ''0x00'',
''domain'':
''0x0000'', ''key'':
''41:00.1'', ''bus'': ''0x41'',
''vdevfn'': ''0x100'', ''func'':
''0x1'', ''uuid'':
''e94457db-ac50-04a3-216f-9fb6c8aab1f1''}],
''states'':
[''Initialising'']}
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:790)
XendDomainInfo.hvm_pci_device_insert_dev: {''slot'':
''0x00'', ''domain'':
''0x0000'', ''key'':
''41:00.1'', ''bus'': ''0x41'',
''vdevfn'': ''0x100'', ''func'':
''0x1'', ''uuid'':
''e94457db-ac50-04a3-216f-9fb6c8aab1f1''}
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:41:00.1@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:815) pci: assign device
0000:41:00.1@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:38 7863] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:54:38 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:41:00.1.
[2013-05-02 22:54:39 7863] INFO (pciquirk:92) NO quirks found for PCI
device [1002:0002:1458:0002]
[2013-05-02 22:54:39 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:0002:1458:0002]
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xbff9c000/0x4000 pfn 0xbff9c/0x4
[2013-05-02 22:54:39 7863] DEBUG (pciif:351) pci: enabling irq 17
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:893)
XendDomainInfo.pci_device_configure: [''pci'',
[''dev'', [''slot'', ''0x00''],
[''domain'', ''0x0000''],
[''key'', ''04:00.0''],
[''bus'', ''0x04''],
[''vdevfn'',
''0x100''], [''func'', ''0x0''],
[''uuid'',
''fe6ebcc1-2dcc-7337-c98e-88250cb78896'']],
[''state'', ''Initialising''],
[''sub_state'', ''Booting'']]
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:779)
XendDomainInfo.hvm_pci_device_insert: {''devs'':
[{''slot'': ''0x00'',
''domain'':
''0x0000'', ''key'':
''04:00.0'', ''bus'': ''0x04'',
''vdevfn'': ''0x100'', ''func'':
''0x0'', ''uuid'':
''fe6ebcc1-2dcc-7337-c98e-88250cb78896''}],
''states'':
[''Initialising'']}
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:790)
XendDomainInfo.hvm_pci_device_insert_dev: {''slot'':
''0x00'', ''domain'':
''0x0000'', ''key'':
''04:00.0'', ''bus'': ''0x04'',
''vdevfn'': ''0x100'', ''func'':
''0x0'', ''uuid'':
''fe6ebcc1-2dcc-7337-c98e-88250cb78896''}
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:815) pci: assign device
0000:04:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:39 7863] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:54:39 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:04:00.0.
[2013-05-02 22:54:39 7863] INFO (pciquirk:92) NO quirks found for PCI
device [104c:8241:0000:0000]
[2013-05-02 22:54:39 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [104c:8241:0000:0000]
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xdfef0000/0x10000 pfn 0xdfef0/0x10
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xdfeee000/0x2000 pfn 0xdfeee/0x2
[2013-05-02 22:54:39 7863] DEBUG (pciif:351) pci: enabling irq 19

... all OK and running. The gpu does not initialize unless after reboot of
dom0, but that issue was since before.

FAILING setup:
pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ] (as before)
OLD pciif.py (if not ... and dev.irq)

xend.log:
[2013-05-02 22:59:13 9301] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:41:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:59:13 9301] DEBUG (XendDomainInfo:815) pci: assign device
0000:41:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:59:13 9301] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 22:59:13 9301] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 22:59:14 9301] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:59:14 9301] INFO (pciquirk:92) NO quirks found for PCI
device [1002:665c:1458:2269]
[2013-05-02 22:59:14 9301] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:665c:1458:2269]
[2013-05-02 22:59:14 9301] DEBUG (pciif:320) pci: enabling ioport
0xe000/0x100
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xa0000000/0x10000000 pfn 0xa0000/0x10000
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0x9f800000/0x800000 pfn 0x9f800/0x800
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbffc0000/0x40000 pfn 0xbffc0/0x40
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbffa0000/0x20000 pfn 0xbffa0/0x20
[2013-05-02 22:59:14 9301] DEBUG (pciif:351) pci: enabling irq 16
[2013-05-02 22:59:14 9301] INFO (pciquirk:92) NO quirks found for PCI
device [1002:0002:1458:0002]
[2013-05-02 22:59:14 9301] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:0002:1458:0002]
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbff9c000/0x4000 pfn 0xbff9c/0x4
[2013-05-02 22:59:14 9301] DEBUG (pciif:351) pci: enabling irq 17
[2013-05-02 22:59:14 9301] ERROR (XendDomainInfo:2927)
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2914, in _initDomain
    self._createDevices()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2395, in _createDevices
    self.pci_device_configure_boot()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 627, in pci_device_configure_boot
    self.pci_device_configure(dev_sxp, first_dev = first)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 970, in pci_device_configure
    devid = self._createDevice(''pci'', existing_pci_conf)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2326, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
67, in createDevice
    self.setupDevice(config)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
453, in setupDevice
    self.setupOneDevice(d)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
353, in setupOneDevice
    allow_access = True)
Error: (22, ''Invalid argument'')
[2013-05-02 22:59:14 9301] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (22, ''Invalid argument'')
[2013-05-02 22:59:14 9301] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=39
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2401) Destroying device
model
[2013-05-02 22:59:17 9301] INFO (image:615) w8 device model terminated
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vfb/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2406) No device model
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 22:59:17 9301] ERROR (XendDomainInfo:108) Domain construction
failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 106, in create
    vm.start()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (22, ''Invalid argument'')

(end of file)

Any other ordering of the pci = [ ... ] list fails as before, but in
different ways as shown in my earlier test.

/Andreas


2013/5/2 Andreas Falck <falck.andreas.lists@gmail.com>
> Ok, I changed so that the corresponding first lines of code looks like
> this:
>
>         if dev.irq:
>             rc = xc.physdev_map_pirq(domid = fe_domid,
>                                    index = dev.irq,
>                                    pirq  = dev.irq)
>
> (only the first line changed)
> Then, after restarting xend, I get a different failure on line 346, which
> is the last line of the above: "VmError: (17, ''File
exists'')". Full
> xend.log attached below.
>
> I can also do tests with the one device which I still manage to pass
> through (a gpu), if I get specific suggestions on what to look for.
>
> /Andreas
>
> [2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:811)
> XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
> ,msitranslate=1,power_mgmt=1
> [2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:815) pci: assign device
> 0000:04:00.0@100,msitranslate=1,power_mgmt=1
> [2013-05-02 20:41:29 19545] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
> [2013-05-02 20:41:29 19545] INFO (image:538) signalDeviceModel:restore dm
> state to running
> [2013-05-02 20:41:30 19545] INFO (pciquirk:92) NO quirks found for PCI
> device [104c:8241:0000:0000]
> [2013-05-02 20:41:30 19545] DEBUG (pciquirk:135) Permissive mode NOT
> enabled for PCI device [104c:8241:0000:0000]
> [2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
> 0xdfef0000/0x10000 pfn 0xdfef0/0x10
> [2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
> 0xdfeee000/0x2000 pfn 0xdfeee/0x2
> [2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:2927)
> XendDomainInfo.initDomain: exception occurred
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2914, in _initDomain
>     self._createDevices()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2395, in _createDevices
>     self.pci_device_configure_boot()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 627, in pci_device_configure_boot
>     self.pci_device_configure(dev_sxp, first_dev = first)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 970, in pci_device_configure
>     devid = self._createDevice(''pci'', existing_pci_conf)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2326, in _createDevice
>     return self.getDeviceController(deviceClass).createDevice(devConfig)
>   File
>
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
> 67, in createDevice
>     self.setupDevice(config)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py", line
> 453, in setupDevice
>     self.setupOneDevice(d)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py", line
> 346, in setupOneDevice
>     pirq  = dev.irq)
> Error: (17, ''File exists'')
> [2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:488) VM start failed
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 474, in start
>     XendTask.log_progress(31, 60, self._initDomain)
>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py",
line
> 209, in log_progress
>     retval = func(*args, **kwds)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2930, in _initDomain
>     raise VmError(str(exn))
> VmError: (17, ''File exists'')
> [2013-05-02 20:41:30 19545] DEBUG (XendDomainInfo:3071)
> XendDomainInfo.destroy: domid=19
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2401) Destroying device
> model
> [2013-05-02 20:41:32 19545] INFO (image:615) w8 device model terminated
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vfb/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2406) No device model
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
> [2013-05-02 20:41:32 19545] ERROR (XendDomainInfo:108) Domain construction
> failed
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 106, in create
>     vm.start()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 474, in start
>     XendTask.log_progress(31, 60, self._initDomain)
>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py",
line
> 209, in log_progress
>     retval = func(*args, **kwds)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2930, in _initDomain
>     raise VmError(str(exn))
> VmError: (17, ''File exists'')
>
>
>
> 2013/5/2 Jan Beulich <JBeulich@suse.com>
>
>> >>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com>
>> wrote:
>> > 2013/5/2 Jan Beulich <JBeulich@suse.com>
>> >
>> >>
>> >> If you could just try out the tentative solution described in
>> >>
http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
>> >> that would already help.
>> >>
>> >
>> > I will have a look when I come home from work, it will be a few
hours
>> from
>> > now. Just so that I understand it right, is this simply a matter
of
>> editing
>> > pciif.py and commenting out the line
>> >
>> >         if not self.vm.info.is_hvm() and dev.irq:
>> >
>> > so that the conditioned code is executed for all guests?
>>
>> No, not the entire line, just the is_hvm part needs to be dropped.
>>
>> Jan
>>
>>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Ok, I have some progress. It tried also with the device I had always
managed to get through, the radeon 7790 gpu. This worked equally well with
both versions of pciif.py. However, it turned out that with the changed
version, if I pass the gpu first in the pci = [ ... ] list, the other
devices also gets through. This was not the case with the original version
of pciif.py.

If (and only if) i order the passthrough list in the config file so that it
says

pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]

(This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) - then
passthrough of all devices works with the new version of pciif.py ("if
dev.irq:"), but not with the old version ("if not
self.vm.info.is_hvm() and
dev.irq:"). So the second failure seemingly has to do with some property
set or checked only for the first passed through device. Logs follow:

WORKING setup:
pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]
NEW pciif.py (if dev.irq)

xend.log:
[2013-05-02 22:54:38 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:41:00.0.
[2013-05-02 22:54:38 7863] INFO (pciquirk:92) NO quirks found for PCI
device [1002:665c:1458:2269]
[2013-05-02 22:54:38 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:665c:1458:2269]
[2013-05-02 22:54:38 7863] DEBUG (pciif:320) pci: enabling ioport
0xe000/0x100
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xa0000000/0x10000000 pfn 0xa0000/0x10000
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0x9f800000/0x800000 pfn 0x9f800/0x800
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xbffc0000/0x40000 pfn 0xbffc0/0x40
[2013-05-02 22:54:38 7863] DEBUG (pciif:334) pci: enabling iomem
0xbffa0000/0x20000 pfn 0xbffa0/0x20
[2013-05-02 22:54:38 7863] DEBUG (pciif:351) pci: enabling irq 16
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:893)
XendDomainInfo.pci_device_configure: [''pci'',
[''dev'', [''slot'', ''0x00''],
[''domain'', ''0x0000''],
[''key'', ''41:00.1''],
[''bus'', ''0x41''],
[''vdevfn'',
''0x100''], [''func'', ''0x1''],
[''uuid'',
''e94457db-ac50-04a3-216f-9fb6c8aab1f1'']],
[''state'', ''Initialising''],
[''sub_state'', ''Booting'']]
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:779)
XendDomainInfo.hvm_pci_device_insert: {''devs'':
[{''slot'': ''0x00'',
''domain'':
''0x0000'', ''key'':
''41:00.1'', ''bus'': ''0x41'',
''vdevfn'': ''0x100'', ''func'':
''0x1'', ''uuid'':
''e94457db-ac50-04a3-216f-9fb6c8aab1f1''}],
''states'':
[''Initialising'']}
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:790)
XendDomainInfo.hvm_pci_device_insert_dev: {''slot'':
''0x00'', ''domain'':
''0x0000'', ''key'':
''41:00.1'', ''bus'': ''0x41'',
''vdevfn'': ''0x100'', ''func'':
''0x1'', ''uuid'':
''e94457db-ac50-04a3-216f-9fb6c8aab1f1''}
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:41:00.1@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:38 7863] DEBUG (XendDomainInfo:815) pci: assign device
0000:41:00.1@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:38 7863] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:54:38 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:41:00.1.
[2013-05-02 22:54:39 7863] INFO (pciquirk:92) NO quirks found for PCI
device [1002:0002:1458:0002]
[2013-05-02 22:54:39 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:0002:1458:0002]
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xbff9c000/0x4000 pfn 0xbff9c/0x4
[2013-05-02 22:54:39 7863] DEBUG (pciif:351) pci: enabling irq 17
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:893)
XendDomainInfo.pci_device_configure: [''pci'',
[''dev'', [''slot'', ''0x00''],
[''domain'', ''0x0000''],
[''key'', ''04:00.0''],
[''bus'', ''0x04''],
[''vdevfn'',
''0x100''], [''func'', ''0x0''],
[''uuid'',
''fe6ebcc1-2dcc-7337-c98e-88250cb78896'']],
[''state'', ''Initialising''],
[''sub_state'', ''Booting'']]
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:779)
XendDomainInfo.hvm_pci_device_insert: {''devs'':
[{''slot'': ''0x00'',
''domain'':
''0x0000'', ''key'':
''04:00.0'', ''bus'': ''0x04'',
''vdevfn'': ''0x100'', ''func'':
''0x0'', ''uuid'':
''fe6ebcc1-2dcc-7337-c98e-88250cb78896''}],
''states'':
[''Initialising'']}
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:790)
XendDomainInfo.hvm_pci_device_insert_dev: {''slot'':
''0x00'', ''domain'':
''0x0000'', ''key'':
''04:00.0'', ''bus'': ''0x04'',
''vdevfn'': ''0x100'', ''func'':
''0x0'', ''uuid'':
''fe6ebcc1-2dcc-7337-c98e-88250cb78896''}
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:39 7863] DEBUG (XendDomainInfo:815) pci: assign device
0000:04:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:54:39 7863] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:54:39 7863] DEBUG (pciif:169) Reconfiguring PCI device
0000:04:00.0.
[2013-05-02 22:54:39 7863] INFO (pciquirk:92) NO quirks found for PCI
device [104c:8241:0000:0000]
[2013-05-02 22:54:39 7863] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [104c:8241:0000:0000]
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xdfef0000/0x10000 pfn 0xdfef0/0x10
[2013-05-02 22:54:39 7863] DEBUG (pciif:334) pci: enabling iomem
0xdfeee000/0x2000 pfn 0xdfeee/0x2
[2013-05-02 22:54:39 7863] DEBUG (pciif:351) pci: enabling irq 19

... all OK and running. The gpu does not initialize unless after reboot of
dom0, but that issue was since before.

FAILING setup:
pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ] (as before)
OLD pciif.py (if not ... and dev.irq)

xend.log:
[2013-05-02 22:59:13 9301] DEBUG (XendDomainInfo:811)
XendDomainInfo.hvm_pci_device_insert_dev: 0000:41:00.0@100
,msitranslate=1,power_mgmt=1
[2013-05-02 22:59:13 9301] DEBUG (XendDomainInfo:815) pci: assign device
0000:41:00.0@100,msitranslate=1,power_mgmt=1
[2013-05-02 22:59:13 9301] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 22:59:13 9301] DEBUG (image:508) signalDeviceModel: orig_state
is None, retrying
[2013-05-02 22:59:14 9301] INFO (image:538) signalDeviceModel:restore dm
state to running
[2013-05-02 22:59:14 9301] INFO (pciquirk:92) NO quirks found for PCI
device [1002:665c:1458:2269]
[2013-05-02 22:59:14 9301] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:665c:1458:2269]
[2013-05-02 22:59:14 9301] DEBUG (pciif:320) pci: enabling ioport
0xe000/0x100
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xa0000000/0x10000000 pfn 0xa0000/0x10000
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0x9f800000/0x800000 pfn 0x9f800/0x800
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbffc0000/0x40000 pfn 0xbffc0/0x40
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbffa0000/0x20000 pfn 0xbffa0/0x20
[2013-05-02 22:59:14 9301] DEBUG (pciif:351) pci: enabling irq 16
[2013-05-02 22:59:14 9301] INFO (pciquirk:92) NO quirks found for PCI
device [1002:0002:1458:0002]
[2013-05-02 22:59:14 9301] DEBUG (pciquirk:135) Permissive mode NOT enabled
for PCI device [1002:0002:1458:0002]
[2013-05-02 22:59:14 9301] DEBUG (pciif:334) pci: enabling iomem
0xbff9c000/0x4000 pfn 0xbff9c/0x4
[2013-05-02 22:59:14 9301] DEBUG (pciif:351) pci: enabling irq 17
[2013-05-02 22:59:14 9301] ERROR (XendDomainInfo:2927)
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2914, in _initDomain
    self._createDevices()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2395, in _createDevices
    self.pci_device_configure_boot()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 627, in pci_device_configure_boot
    self.pci_device_configure(dev_sxp, first_dev = first)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 970, in pci_device_configure
    devid = self._createDevice(''pci'', existing_pci_conf)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2326, in _createDevice
    return self.getDeviceController(deviceClass).createDevice(devConfig)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
67, in createDevice
    self.setupDevice(config)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
453, in setupDevice
    self.setupOneDevice(d)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py",
line
353, in setupOneDevice
    allow_access = True)
Error: (22, ''Invalid argument'')
[2013-05-02 22:59:14 9301] ERROR (XendDomainInfo:488) VM start failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (22, ''Invalid argument'')
[2013-05-02 22:59:14 9301] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=39
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2401) Destroying device
model
[2013-05-02 22:59:17 9301] INFO (image:615) w8 device model terminated
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vfb/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2406) No device model
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2408) Releasing devices
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:2414) Removing vbd/5632
[2013-05-02 22:59:17 9301] DEBUG (XendDomainInfo:1276)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2013-05-02 22:59:17 9301] ERROR (XendDomainInfo:108) Domain construction
failed
Traceback (most recent call last):
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 106, in create
    vm.start()
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 474, in start
    XendTask.log_progress(31, 60, self._initDomain)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
209,
in log_progress
    retval = func(*args, **kwds)
  File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
line 2930, in _initDomain
    raise VmError(str(exn))
VmError: (22, ''Invalid argument'')

(end of file)

Any other ordering of the pci = [ ... ] list fails as before, but in
different ways as shown in my earlier test.

/Andreas


2013/5/2 Andreas Falck <falck.andreas.lists@gmail.com>
> Ok, I changed so that the corresponding first lines of code looks like
> this:
>
>         if dev.irq:
>             rc = xc.physdev_map_pirq(domid = fe_domid,
>                                    index = dev.irq,
>                                    pirq  = dev.irq)
>
> (only the first line changed)
> Then, after restarting xend, I get a different failure on line 346, which
> is the last line of the above: "VmError: (17, ''File
exists'')". Full
> xend.log attached below.
>
> I can also do tests with the one device which I still manage to pass
> through (a gpu), if I get specific suggestions on what to look for.
>
> /Andreas
>
> [2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:811)
> XendDomainInfo.hvm_pci_device_insert_dev: 0000:04:00.0@100
> ,msitranslate=1,power_mgmt=1
> [2013-05-02 20:41:29 19545] DEBUG (XendDomainInfo:815) pci: assign device
> 0000:04:00.0@100,msitranslate=1,power_mgmt=1
> [2013-05-02 20:41:29 19545] DEBUG (image:508) signalDeviceModel:
> orig_state is None, retrying
> [2013-05-02 20:41:29 19545] INFO (image:538) signalDeviceModel:restore dm
> state to running
> [2013-05-02 20:41:30 19545] INFO (pciquirk:92) NO quirks found for PCI
> device [104c:8241:0000:0000]
> [2013-05-02 20:41:30 19545] DEBUG (pciquirk:135) Permissive mode NOT
> enabled for PCI device [104c:8241:0000:0000]
> [2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
> 0xdfef0000/0x10000 pfn 0xdfef0/0x10
> [2013-05-02 20:41:30 19545] DEBUG (pciif:334) pci: enabling iomem
> 0xdfeee000/0x2000 pfn 0xdfeee/0x2
> [2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:2927)
> XendDomainInfo.initDomain: exception occurred
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2914, in _initDomain
>     self._createDevices()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2395, in _createDevices
>     self.pci_device_configure_boot()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 627, in pci_device_configure_boot
>     self.pci_device_configure(dev_sxp, first_dev = first)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 970, in pci_device_configure
>     devid = self._createDevice(''pci'', existing_pci_conf)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2326, in _createDevice
>     return self.getDeviceController(deviceClass).createDevice(devConfig)
>   File
>
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/DevController.py",
line
> 67, in createDevice
>     self.setupDevice(config)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py", line
> 453, in setupDevice
>     self.setupOneDevice(d)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/server/pciif.py", line
> 346, in setupOneDevice
>     pirq  = dev.irq)
> Error: (17, ''File exists'')
> [2013-05-02 20:41:30 19545] ERROR (XendDomainInfo:488) VM start failed
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 474, in start
>     XendTask.log_progress(31, 60, self._initDomain)
>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py",
line
> 209, in log_progress
>     retval = func(*args, **kwds)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2930, in _initDomain
>     raise VmError(str(exn))
> VmError: (17, ''File exists'')
> [2013-05-02 20:41:30 19545] DEBUG (XendDomainInfo:3071)
> XendDomainInfo.destroy: domid=19
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2401) Destroying device
> model
> [2013-05-02 20:41:32 19545] INFO (image:615) w8 device model terminated
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vfb/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2406) No device model
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2408) Releasing devices
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/832
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:2414) Removing vbd/5632
> [2013-05-02 20:41:32 19545] DEBUG (XendDomainInfo:1276)
> XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
> [2013-05-02 20:41:32 19545] ERROR (XendDomainInfo:108) Domain construction
> failed
>
> Traceback (most recent call last):
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 106, in create
>     vm.start()
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 474, in start
>     XendTask.log_progress(31, 60, self._initDomain)
>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py",
line
> 209, in log_progress
>     retval = func(*args, **kwds)
>   File
"/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
> line 2930, in _initDomain
>     raise VmError(str(exn))
> VmError: (17, ''File exists'')
>
>
>
> 2013/5/2 Jan Beulich <JBeulich@suse.com>
>
>> >>> On 02.05.13 at 14:42, Andreas Falck
<falck.andreas.lists@gmail.com>
>> wrote:
>> > 2013/5/2 Jan Beulich <JBeulich@suse.com>
>> >
>> >>
>> >> If you could just try out the tentative solution described in
>> >>
http://lists.xen.org/archives/html/xen-devel/2013-05/msg00145.html
>> >> that would already help.
>> >>
>> >
>> > I will have a look when I come home from work, it will be a few
hours
>> from
>> > now. Just so that I understand it right, is this simply a matter
of
>> editing
>> > pciif.py and commenting out the line
>> >
>> >         if not self.vm.info.is_hvm() and dev.irq:
>> >
>> > so that the conditioned code is executed for all guests?
>>
>> No, not the entire line, just the is_hvm part needs to be dropped.
>>
>> Jan
>>
>>
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

>>> On 02.05.13 at 23:07, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> Ok, I have some progress. It tried also with the device I had always
> managed to get through, the radeon 7790 gpu. This worked equally well with
> both versions of pciif.py. However, it turned out that with the changed
> version, if I pass the gpu first in the pci = [ ... ] list, the other
> devices also gets through. This was not the case with the original version
> of pciif.py.
> 
> If (and only if) i order the passthrough list in the config file so that it
> says
> 
> pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]
> 
> (This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) - then
> passthrough of all devices works with the new version of pciif.py ("if
> dev.irq:"), but not with the old version ("if not
self.vm.info.is_hvm() and
> dev.irq:"). So the second failure seemingly has to do with some
property
> set or checked only for the first passed through device. Logs follow:
Sending xend logs here is only marginally useful, as the errors
quite certainly originate in the hypervisor. Especially considering
that the ordering of devices matters (which is quite irritating to
me), but also with the logs here now showing the -EEXIST error
that your earlier mail mentioned, we have to rely on you to help
with tracking down the root cause of this (by instrumenting the
affected hypervisor paths, i.e. extending on the debugging
patch that Andrew sent). And without you explicitly saying so
we can''t even be sure there aren''t (when run at maximum log
level) already messages in the hypervisor log that might provide
some further insight.

Also, please don''t cross post - pick either of xen-devel or
xen-users, but not both.

Jan

Sorry, I''ll stick to xen-devel then, even though I am not on the list
(I
can change the latter of course).

Since I run xen 4.1 (specifically the precompiled 4.1.3-3ubuntu1.5) I guess
I cannot apply Andrew''s patch directly (unless the file hasn''t
changed
between the versions)? But I could probably figure out where in the
4.1.3-3ubuntu1.5 sources to insert the code from the patch, if I compile it
from source.

I can do some more testing throughout the weekend. Could you give me some
directions on what I should test, which logs and info to provide, and how
to maximize debug output from tools and from the hypervisor. That would
maximize my chances to get the relevant information. I guess that at a
minimum we want a failing and a succeding case with and without the change
in pciif.py?

''xm dmesg'' didn''t show me anything unusual when
testing, but that was
without any added debug-keys.

Should I pastebin log outputs or should I include them in emails to keep
them searchable?

/Andreas


2013/5/3 Jan Beulich <JBeulich@suse.com>
> >>> On 02.05.13 at 23:07, Andreas Falck
<falck.andreas.lists@gmail.com>
> wrote:
> > Ok, I have some progress. It tried also with the device I had always
> > managed to get through, the radeon 7790 gpu. This worked equally well
> with
> > both versions of pciif.py. However, it turned out that with the
changed
> > version, if I pass the gpu first in the pci = [ ... ] list, the other
> > devices also gets through. This was not the case with the original
> version
> > of pciif.py.
> >
> > If (and only if) i order the passthrough list in the config file so
that
> it
> > says
> >
> > pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]
> >
> > (This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) - then
> > passthrough of all devices works with the new version of pciif.py
("if
> > dev.irq:"), but not with the old version ("if not
self.vm.info.is_hvm()
> and
> > dev.irq:"). So the second failure seemingly has to do with some
property
> > set or checked only for the first passed through device. Logs follow:
>
> Sending xend logs here is only marginally useful, as the errors
> quite certainly originate in the hypervisor. Especially considering
> that the ordering of devices matters (which is quite irritating to
> me), but also with the logs here now showing the -EEXIST error
> that your earlier mail mentioned, we have to rely on you to help
> with tracking down the root cause of this (by instrumenting the
> affected hypervisor paths, i.e. extending on the debugging
> patch that Andrew sent). And without you explicitly saying so
> we can''t even be sure there aren''t (when run at maximum
log
> level) already messages in the hypervisor log that might provide
> some further insight.
>
> Also, please don''t cross post - pick either of xen-devel or
> xen-users, but not both.
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 03.05.13 at 15:31, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> Sorry, I''ll stick to xen-devel then, even though I am not on the
list (I
> can change the latter of course).
> 
> Since I run xen 4.1 (specifically the precompiled 4.1.3-3ubuntu1.5) I guess
> I cannot apply Andrew''s patch directly (unless the file
hasn''t changed
> between the versions)? But I could probably figure out where in the
> 4.1.3-3ubuntu1.5 sources to insert the code from the patch, if I compile it
> from source.
Andrew''s patch alone won''t tell us anything new. We need
instrumentation in the physdev_map_pirq() path for the problem
you''re seeing now.
> I can do some more testing throughout the weekend. Could you give me some
> directions on what I should test, which logs and info to provide, and how
> to maximize debug output from tools and from the hypervisor. That would
> maximize my chances to get the relevant information. I guess that at a
> minimum we want a failing and a succeding case with and without the change
> in pciif.py?
> 
> ''xm dmesg'' didn''t show me anything unusual when
testing, but that was
> without any added debug-keys.
That''s odd - at least when you saw the -EEXIST I would have expect
some extra message to be there (because the only place where this
error gets returned in physdev.c has an accompanying message).
Please check again after adding "loglvl=all guest_loglvl=all".

Jan

On 03/05/2013 14:31, Andreas Falck wrote:
> Sorry, I''ll stick to xen-devel then, even though I am not on the
list
> (I can change the latter of course).
>
> Since I run xen 4.1 (specifically the precompiled 4.1.3-3ubuntu1.5) I
> guess I cannot apply Andrew''s patch directly (unless the file
hasn''t
> changed between the versions)? But I could probably figure out where
> in the 4.1.3-3ubuntu1.5 sources to insert the code from the patch, if
> I compile it from source.
Attached is the same debugging patch against 4.1.  If you grab the src
rpm, you should be able to add it as another patch to the specfile and
use rpmbuild.  Or you can just build straight from source, whichever is
easier.

~Andrew
>
> I can do some more testing throughout the weekend. Could you give me
> some directions on what I should test, which logs and info to provide,
> and how to maximize debug output from tools and from the hypervisor.
> That would maximize my chances to get the relevant information. I
> guess that at a minimum we want a failing and a succeding case with
> and without the change in pciif.py?
>
> ''xm dmesg'' didn''t show me anything unusual when
testing, but that was
> without any added debug-keys.
>
> Should I pastebin log outputs or should I include them in emails to
> keep them searchable?
>
> /Andreas
>
>
> 2013/5/3 Jan Beulich <JBeulich@suse.com
<mailto:JBeulich@suse.com>>
>
>     >>> On 02.05.13 at 23:07, Andreas Falck
>     <falck.andreas.lists@gmail.com
>     <mailto:falck.andreas.lists@gmail.com>> wrote:
>     > Ok, I have some progress. It tried also with the device I had
always
>     > managed to get through, the radeon 7790 gpu. This worked equally
>     well with
>     > both versions of pciif.py. However, it turned out that with the
>     changed
>     > version, if I pass the gpu first in the pci = [ ... ] list, the
>     other
>     > devices also gets through. This was not the case with the
>     original version
>     > of pciif.py.
>     >
>     > If (and only if) i order the passthrough list in the config file
>     so that it
>     > says
>     >
>     > pci = [ ''41:00.0'', ''41:00.1'',
''04:00.0'' ]
>     >
>     > (This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) -
then
>     > passthrough of all devices works with the new version of
>     pciif.py ("if
>     > dev.irq:"), but not with the old version ("if not
>     self.vm.info.is_hvm() and
>     > dev.irq:"). So the second failure seemingly has to do with
some
>     property
>     > set or checked only for the first passed through device. Logs
>     follow:
>
>     Sending xend logs here is only marginally useful, as the errors
>     quite certainly originate in the hypervisor. Especially considering
>     that the ordering of devices matters (which is quite irritating to
>     me), but also with the logs here now showing the -EEXIST error
>     that your earlier mail mentioned, we have to rely on you to help
>     with tracking down the root cause of this (by instrumenting the
>     affected hypervisor paths, i.e. extending on the debugging
>     patch that Andrew sent). And without you explicitly saying so
>     we can''t even be sure there aren''t (when run at
maximum log
>     level) already messages in the hypervisor log that might provide
>     some further insight.
>
>     Also, please don''t cross post - pick either of xen-devel or
>     xen-users, but not both.
>
>     Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 03.05.13 at 15:57, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 03/05/2013 14:31, Andreas Falck wrote:
>> Sorry, I''ll stick to xen-devel then, even though I am not on
the list
>> (I can change the latter of course).
>>
>> Since I run xen 4.1 (specifically the precompiled 4.1.3-3ubuntu1.5) I
>> guess I cannot apply Andrew''s patch directly (unless the file
hasn''t
>> changed between the versions)? But I could probably figure out where
>> in the 4.1.3-3ubuntu1.5 sources to insert the code from the patch, if
>> I compile it from source.
> 
> Attached is the same debugging patch against 4.1.  If you grab the src
> rpm, you should be able to add it as another patch to the specfile and
> use rpmbuild.  Or you can just build straight from source, whichever is
> easier.
But from what Andreas told us he''s not even getting here
anymore after the small xend adjustment. As written earlier,
he''ll need to add some extra printing to the physdev_map_pirq()
path.

Jan

>
> But from what Andreas told us he''s not even getting here
> anymore after the small xend adjustment. As written earlier,
> he''ll need to add some extra printing to the physdev_map_pirq()
> path.

Just tell me what I should add and I''ll try to add it. If we have
concluded
that the change in pciif.py is valid, I can skip that part of the debugging
search space. Unless you want more information from the error as of before
the change.

/Andreas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 03.05.13 at 16:56, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
>> 
>> But from what Andreas told us he''s not even getting here
>> anymore after the small xend adjustment. As written earlier,
>> he''ll need to add some extra printing to the
physdev_map_pirq()
>> path.
> 
> 
> Just tell me what I should add and I''ll try to add it. If we have
concluded
> that the change in pciif.py is valid, I can skip that part of the debugging
> search space. Unless you want more information from the error as of before
> the change.
The reason for the error before that change is understood (hence
the adjustment to the xend code).

I can of course work on handing you a debugging patch, but you
doing so yourself would improve the turnaround quite significantly.

And yes, even without any debugging patch, seeing a full hypervisor
log especially for the case where you got the EEXIST error in xend
might already help.

Jan

Hi,

I started by looking at xm dmesg with max log level, before adding debug
code anywhere. It turns out that when starting the failing config, I get
(only) this message:

(XEN) physdev.c:209: dom4: pirq 19 conflicts with irq 19

 That is when I pass the USB controller first, "pci = [04:00.0, 41:00.0,
41:00.1]" If I try to pass only the HDMI audio (pci = 41:00.1), I get:

(XEN) physdev.c:209: dom5: pirq 17 conflicts with irq 17

It may be also in the standard log level, I might have missed it before.

Output from ''xm dmesg'' from running the working config
"pci = [ 41:00.0,
41:00.1, 04:00.0 ]", with which the devices gets irq:s 16, 17 and 19 (in
that order):

http://pastebin.com/NNWTrk8H

Output from ''xm dmesg'' before starting any VM:

http://pastebin.com/QmZJpvP9

The last line

(XEN) physdev.c:171: dom0: wrong map_pirq type 3

has always been around on my system, as long as I can remember. I realize
now that it may be related.

From your answers so far I assume that debugging further is simply a matter
of putting printfs at sensible points in physdev_map_pirq() and/or dumping
values. I''ll give compiling a try during the weekend.

Regards,
Andreas


2013/5/3 Jan Beulich <JBeulich@suse.com>
> >>> On 03.05.13 at 16:56, Andreas Falck
<falck.andreas.lists@gmail.com>
> wrote:
> >>
> >> But from what Andreas told us he''s not even getting here
> >> anymore after the small xend adjustment. As written earlier,
> >> he''ll need to add some extra printing to the
physdev_map_pirq()
> >> path.
> >
> >
> > Just tell me what I should add and I''ll try to add it. If we
have
> concluded
> > that the change in pciif.py is valid, I can skip that part of the
> debugging
> > search space. Unless you want more information from the error as of
> before
> > the change.
>
> The reason for the error before that change is understood (hence
> the adjustment to the xend code).
>
> I can of course work on handing you a debugging patch, but you
> doing so yourself would improve the turnaround quite significantly.
>
> And yes, even without any debugging patch, seeing a full hypervisor
> log especially for the case where you got the EEXIST error in xend
> might already help.
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hi again,

I tried adding some debugging statements in physdev_map_pirq. I have
attached the physdev.c with my debug statements, a hypervisor log from
testing, and the output of lspci -vv for my three devices.

First briefly my understanding of the function, including where I put the
log messages:

// - comments denote what I''ve added
/**/ - comments denote my assumption on what the code does

int physdev_map_pirq(physdev_map_pirq *map) {
 // added log AF1, dumping most of *map

 switch(map->type) /* MSI | GSI */
 // added log AF2 for clarifying MSI/GSI case for myself
 case GSI:
     /* fetching real irq */
     // add log AF2.5: real irq
 case MSI:
     /* invent irq */
 /* end switch*/

 /* some mutex locking here */

     pirq = domain_irq_to_pirq(d, irq); /* lookup in host-specific table */
    // added log AF3, map->pirq= ..., pirq = ...

    if ( map->pirq < 0 )
    {
        if (pirq)
            /* "already mapped" error */
        else
            // added log AF4
    }
    else
    {
        if ( pirq && pirq != map->pirq )
        {
             /* failing case follows */
             // added log AF4.5: pirq = ...
            dprintk(XENLOG_G_ERR, "dom%d: pirq %d conflicts with irq
%d\n",
                    d->domain_id, map->index, map->pirq);
            ret = -EEXIST;
            goto done;
        }
        else
        {
            // added log AF5 "else case instead of EEXIST"
            pirq = map->pirq;
        }
    }

    map->pirq = pirq;     /* when everything is ok */
     // added log AF6: map->pirq=...

 /* mutex unlocking */
 /* cleaning up */
 }

Output from xm dmesg with vm creation details is attached. Whereas I''m
unsure about the meaning of map->index, I note that in the failing case
with only device 04:00.0 passed we see (the GSI cases seem the relevant
ones, so I omit the MSI cases here. Full log is attached.):

[FAILING]
(XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
map->pirq-1, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq-1, pirq0
(XEN) physdev.c:205: AF4: got previously free pirq=16
(XEN) physdev.c:236: AF6: final map->pirq: 16
...
(XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
map->pirq19, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq19, pirq16
(XEN) physdev.c:219: AF4.5: pirq right before EEXIST error: 16
(XEN) physdev.c:221: dom1: pirq 19 conflicts with irq 19

I find it confusing that the error statement on the last line reports "pirq
19", while the value being reported is really from
"map->index", according
to the code above. My AF4.5 is executed right before, so the value of the
local variable pirq is then 16 (while map->pirq == map->index == 19). Can
it be that the code assumes that local "pirq" and
"map->index" at this
point of the code should have the same value, and some other new code has
invalidated the assumption? Relying on the same assumption somewhere else
may then have caused the error.

In the working case, when all three devices are passed, [41:00.0, 41:00.1,
04:00.0], I see what seems like multiple instances of setting up each
device. The first seems to correspond to 41:00.0:

[WORKING]
(XEN) physdev.c:98: AF1: map->domid2, map->type1, map->index16,
map->pirq-1, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=16 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq-1, pirq0
(XEN) physdev.c:205: AF4: got previously free pirq=16
(XEN) physdev.c:236: AF6: final map->pirq: 16
...
(XEN) physdev.c:98: AF1: map->domid2, map->type1, map->index16,
map->pirq16, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=16 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq16, pirq16
(XEN) physdev.c:227: AF5: else case instead of EEXIST error
(XEN) physdev.c:236: AF6: final map->pirq: 16

(p)IRQs match all the way. Then:

(XEN) physdev.c:98: AF1: map->domid2, map->type1, map->index17,
map->pirq17, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=17 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq17, pirq0
(XEN) physdev.c:227: AF5: else case instead of EEXIST error
(XEN) physdev.c:236: AF6: final map->pirq: 17
(XEN) physdev.c:98: AF1: map->domid2, map->type1, map->index19,
map->pirq19, map->bus0, map->devfn0, map->entry_nr0
(XEN) physdev.c:131: AF2: map->type=GSI
(XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
map->index instead or fail with error)
(XEN) physdev.c:188: AF3: after getting pirq: map->pirq19, pirq0
(XEN) physdev.c:227: AF5: else case instead of EEXIST error
(XEN) physdev.c:236: AF6: final map->pirq: 19

41:00.1 and 04:00.0 seem to be correctly set up on "first try",
finding the
"right" irq. Then follows some repetitions of the function, sometimes
with
errors/warnings, sometimes without. See the attached log, I can''t
really
decide if they are needed or if they are redundant. From the above it seems
that the get_free_pirq function plays a role. I haven''t looked further
into
it.

Regards,
Andreas



2013/5/3 Andreas Falck <falck.andreas.lists@gmail.com>
> Hi,
>
> I started by looking at xm dmesg with max log level, before adding debug
> code anywhere. It turns out that when starting the failing config, I get
> (only) this message:
>
> (XEN) physdev.c:209: dom4: pirq 19 conflicts with irq 19
>
>  That is when I pass the USB controller first, "pci = [04:00.0,
41:00.0,
> 41:00.1]" If I try to pass only the HDMI audio (pci = 41:00.1), I get:
>
> (XEN) physdev.c:209: dom5: pirq 17 conflicts with irq 17
>
> It may be also in the standard log level, I might have missed it before.
>
> Output from ''xm dmesg'' from running the working config
"pci = [ 41:00.0,
> 41:00.1, 04:00.0 ]", with which the devices gets irq:s 16, 17 and 19
(in
> that order):
>
> http://pastebin.com/NNWTrk8H
>
> Output from ''xm dmesg'' before starting any VM:
>
> http://pastebin.com/QmZJpvP9
>
> The last line
>
> (XEN) physdev.c:171: dom0: wrong map_pirq type 3
>
> has always been around on my system, as long as I can remember. I realize
> now that it may be related.
>
> From your answers so far I assume that debugging further is simply a
> matter of putting printfs at sensible points in physdev_map_pirq() and/or
> dumping values. I''ll give compiling a try during the weekend.
>
> Regards,
> Andreas
>
>
> 2013/5/3 Jan Beulich <JBeulich@suse.com>
>
>> >>> On 03.05.13 at 16:56, Andreas Falck
<falck.andreas.lists@gmail.com>
>> wrote:
>> >>
>> >> But from what Andreas told us he''s not even getting
here
>> >> anymore after the small xend adjustment. As written earlier,
>> >> he''ll need to add some extra printing to the
physdev_map_pirq()
>> >> path.
>> >
>> >
>> > Just tell me what I should add and I''ll try to add it. If
we have
>> concluded
>> > that the change in pciif.py is valid, I can skip that part of the
>> debugging
>> > search space. Unless you want more information from the error as
of
>> before
>> > the change.
>>
>> The reason for the error before that change is understood (hence
>> the adjustment to the xend code).
>>
>> I can of course work on handing you a debugging patch, but you
>> doing so yourself would improve the turnaround quite significantly.
>>
>> And yes, even without any debugging patch, seeing a full hypervisor
>> log especially for the case where you got the EEXIST error in xend
>> might already help.
>>
>> Jan
>>
>>
>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> [FAILING]
> (XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
> map->pirq-1, map->bus0, map->devfn0, map->entry_nr0
> (XEN) physdev.c:131: AF2: map->type=GSI
> (XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
> map->index instead or fail with error)
> (XEN) physdev.c:188: AF3: after getting pirq: map->pirq-1, pirq0
> (XEN) physdev.c:205: AF4: got previously free pirq=16
> (XEN) physdev.c:236: AF6: final map->pirq: 16
> ...
> (XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
> map->pirq19, map->bus0, map->devfn0, map->entry_nr0
> (XEN) physdev.c:131: AF2: map->type=GSI
> (XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
> map->index instead or fail with error)
> (XEN) physdev.c:188: AF3: after getting pirq: map->pirq19, pirq16
> (XEN) physdev.c:219: AF4.5: pirq right before EEXIST error: 16
> (XEN) physdev.c:221: dom1: pirq 19 conflicts with irq 19
This makes matters pretty clear (minus finding the places where
the calls originate from in xend): The tool stack ought to settle on
whether it wants a 1:1 mapping for GSIs (in which case it needs to
pass in ->irq and ->index set to the same value) or whether it
wants Xen to establish a mapping (in which case it has to _always_
pass in -1 for ->pirq).

Of course we could try to work around this in the hypervisor:
Rather than calling get_free_pirq() unconditionally if map->pirq
is negative and pirq is zero, we could first see whether we can
use the 1:1 mapping slot (i.e. if it''s not in use or already set up
for a 1:1 mapping). But to me that''s a last resort thing, should
we find that fixing xend really isn''t doable with reasonable effort.

The working case results from get_free_pirq() being first called
for IRQ16, and with a low-to-high allocation strategy this happens
to produce a 1:1 mapping (as 16 is the first slot available).

What I''m mildly concerned about is
>(XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
>map->index instead or fail with error)
in both the working a failure cases - arch_domain_create() sets
up only IRQs below 16, so without any other action done by the
tool stack the translation should return zero here. But of course
that doesn''t make any difference to the control flow further down
as the immediately following code - as your added messages also
states - would use map->index anyway.

Nevertheless it might be worth hunting down where that setup is
being done (domain_pirq_to_irq() simply being a read of
d->arch.pirq_irq[], it ought to be one of the few places where
that array gets written to with a positive value.

Jan

>>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
> I tried adding some debugging statements in physdev_map_pirq. I have
> attached the physdev.c with my debug statements, a hypervisor log from
> testing, and the output of lspci -vv for my three devices.
Since I didn''t hear anything from either of you anymore, I went
through the (not very familiar to me) tool stack code again, and
found that qemu and xend/libxl fundamentally disagree about the
model to be used. Qemu wants to allocate PIRQs while xend/libxl
want a 1:1 mapping. Allocating after having created a 1:1 mapping
works by returning the 1:1 mapping as allocation result, so as long
as libxl completes its setup before launching qemu, it would be
obvious why things work there. Consequently I assume that xend
launches qemu quite a bit earlier in the process of creating a new
domain, and the result of an attempt to establish a 1:1 mapping
when a different mapping was already established is dependent on
the specific interrupt numbers (i.e. also explains the observations
one of you made).

Since the tool stack as a whole really ought to use a consistent
model, and since the 1:1 mapping model for non-MSI IRQs seems
quite natural, the below/attached patch takes care of enforcing
a 1:1 mapping in libxc when allocation is being requested by the
caller. Ian, Ian - do you foresee any problem with this?

Please both of you give this a try and let us know of the results
(patch applies cleanly to all of -unstable, 4.2, and 4.1).

Jan

--- a/tools/libxc/xc_physdev.c
+++ b/tools/libxc/xc_physdev.c
@@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
     map.domid = domid;
     map.type = MAP_PIRQ_TYPE_GSI;
     map.index = index;
-    map.pirq = *pirq;
+    map.pirq = *pirq < 0 ? index : *pirq;
 
     rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map));
 
--- a/tools/python/xen/xend/server/pciif.py
+++ b/tools/python/xen/xend/server/pciif.py
@@ -340,7 +340,7 @@ class PciController(DevController):
                 raise VmError((''pci: failed to configure I/O memory on
device ''+
                             ''%s - errno=%d'')%(dev.name,rc))
 
-        if not self.vm.info.is_hvm() and dev.irq:
+        if dev.irq > 0:
             rc = xc.physdev_map_pirq(domid = fe_domid,
                                    index = dev.irq,
                                    pirq  = dev.irq)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Thanks Jan,

 I''ll try this tonight and report back.

 Many thanks.

 Gordan

 On Tue, 14 May 2013 15:01:11 +0100, "Jan Beulich"
<JBeulich@suse.com>
 wrote:
>>>> On 05.05.13 at 21:33, Andreas Falck 
>>>> <falck.andreas.lists@gmail.com> wrote:
>> I tried adding some debugging statements in physdev_map_pirq. I have
>> attached the physdev.c with my debug statements, a hypervisor log 
>> from
>> testing, and the output of lspci -vv for my three devices.
>
> Since I didn''t hear anything from either of you anymore, I went
> through the (not very familiar to me) tool stack code again, and
> found that qemu and xend/libxl fundamentally disagree about the
> model to be used. Qemu wants to allocate PIRQs while xend/libxl
> want a 1:1 mapping. Allocating after having created a 1:1 mapping
> works by returning the 1:1 mapping as allocation result, so as long
> as libxl completes its setup before launching qemu, it would be
> obvious why things work there. Consequently I assume that xend
> launches qemu quite a bit earlier in the process of creating a new
> domain, and the result of an attempt to establish a 1:1 mapping
> when a different mapping was already established is dependent on
> the specific interrupt numbers (i.e. also explains the observations
> one of you made).
>
> Since the tool stack as a whole really ought to use a consistent
> model, and since the 1:1 mapping model for non-MSI IRQs seems
> quite natural, the below/attached patch takes care of enforcing
> a 1:1 mapping in libxc when allocation is being requested by the
> caller. Ian, Ian - do you foresee any problem with this?
>
> Please both of you give this a try and let us know of the results
> (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>
> Jan
>
> --- a/tools/libxc/xc_physdev.c
> +++ b/tools/libxc/xc_physdev.c
> @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>      map.domid = domid;
>      map.type = MAP_PIRQ_TYPE_GSI;
>      map.index = index;
> -    map.pirq = *pirq;
> +    map.pirq = *pirq < 0 ? index : *pirq;
>
>      rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map));
>
> --- a/tools/python/xen/xend/server/pciif.py
> +++ b/tools/python/xen/xend/server/pciif.py
> @@ -340,7 +340,7 @@ class PciController(DevController):
>                  raise VmError((''pci: failed to configure I/O
memory
> on device ''+
>                              ''%s -
errno=%d'')%(dev.name,rc))
>
> -        if not self.vm.info.is_hvm() and dev.irq:
> +        if dev.irq > 0:
>              rc = xc.physdev_map_pirq(domid = fe_domid,
>                                     index = dev.irq,
>                                     pirq  = dev.irq)

Bad news, I''m afraid - I still get error "22, invalid
argument" with
this patch.

Gordan

On 05/14/2013 03:01 PM, Jan Beulich wrote:
>>>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
>> I tried adding some debugging statements in physdev_map_pirq. I have
>> attached the physdev.c with my debug statements, a hypervisor log from
>> testing, and the output of lspci -vv for my three devices.
>
> Since I didn''t hear anything from either of you anymore, I went
> through the (not very familiar to me) tool stack code again, and
> found that qemu and xend/libxl fundamentally disagree about the
> model to be used. Qemu wants to allocate PIRQs while xend/libxl
> want a 1:1 mapping. Allocating after having created a 1:1 mapping
> works by returning the 1:1 mapping as allocation result, so as long
> as libxl completes its setup before launching qemu, it would be
> obvious why things work there. Consequently I assume that xend
> launches qemu quite a bit earlier in the process of creating a new
> domain, and the result of an attempt to establish a 1:1 mapping
> when a different mapping was already established is dependent on
> the specific interrupt numbers (i.e. also explains the observations
> one of you made).
>
> Since the tool stack as a whole really ought to use a consistent
> model, and since the 1:1 mapping model for non-MSI IRQs seems
> quite natural, the below/attached patch takes care of enforcing
> a 1:1 mapping in libxc when allocation is being requested by the
> caller. Ian, Ian - do you foresee any problem with this?
>
> Please both of you give this a try and let us know of the results
> (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>
> Jan
>
> --- a/tools/libxc/xc_physdev.c
> +++ b/tools/libxc/xc_physdev.c
> @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>       map.domid = domid;
>       map.type = MAP_PIRQ_TYPE_GSI;
>       map.index = index;
> -    map.pirq = *pirq;
> +    map.pirq = *pirq < 0 ? index : *pirq;
>
>       rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map));
>
> --- a/tools/python/xen/xend/server/pciif.py
> +++ b/tools/python/xen/xend/server/pciif.py
> @@ -340,7 +340,7 @@ class PciController(DevController):
>                   raise VmError((''pci: failed to configure I/O
memory on device ''+
>                               ''%s -
errno=%d'')%(dev.name,rc))
>
> -        if not self.vm.info.is_hvm() and dev.irq:
> +        if dev.irq > 0:
>               rc = xc.physdev_map_pirq(domid = fe_domid,
>                                      index = dev.irq,
>                                      pirq  = dev.irq)
>
>

>>> On 14.05.13 at 21:30, Gordan Bobic <gordan@bobich.net> wrote:
> Bad news, I''m afraid - I still get error "22, invalid
argument" with
> this patch.
It would of course help to know precisely where this error is being
observed, the more that the xend change alone was reported to
convert the original EINVAL into EEXIST in another place.

Jan
> On 05/14/2013 03:01 PM, Jan Beulich wrote:
>>>>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com> wrote:
>>> I tried adding some debugging statements in physdev_map_pirq. I
have
>>> attached the physdev.c with my debug statements, a hypervisor log
from
>>> testing, and the output of lspci -vv for my three devices.
>>
>> Since I didn''t hear anything from either of you anymore, I
went
>> through the (not very familiar to me) tool stack code again, and
>> found that qemu and xend/libxl fundamentally disagree about the
>> model to be used. Qemu wants to allocate PIRQs while xend/libxl
>> want a 1:1 mapping. Allocating after having created a 1:1 mapping
>> works by returning the 1:1 mapping as allocation result, so as long
>> as libxl completes its setup before launching qemu, it would be
>> obvious why things work there. Consequently I assume that xend
>> launches qemu quite a bit earlier in the process of creating a new
>> domain, and the result of an attempt to establish a 1:1 mapping
>> when a different mapping was already established is dependent on
>> the specific interrupt numbers (i.e. also explains the observations
>> one of you made).
>>
>> Since the tool stack as a whole really ought to use a consistent
>> model, and since the 1:1 mapping model for non-MSI IRQs seems
>> quite natural, the below/attached patch takes care of enforcing
>> a 1:1 mapping in libxc when allocation is being requested by the
>> caller. Ian, Ian - do you foresee any problem with this?
>>
>> Please both of you give this a try and let us know of the results
>> (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>>
>> Jan
>>
>> --- a/tools/libxc/xc_physdev.c
>> +++ b/tools/libxc/xc_physdev.c
>> @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>>       map.domid = domid;
>>       map.type = MAP_PIRQ_TYPE_GSI;
>>       map.index = index;
>> -    map.pirq = *pirq;
>> +    map.pirq = *pirq < 0 ? index : *pirq;
>>
>>       rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map,
sizeof(map));
>>
>> --- a/tools/python/xen/xend/server/pciif.py
>> +++ b/tools/python/xen/xend/server/pciif.py
>> @@ -340,7 +340,7 @@ class PciController(DevController):
>>                   raise VmError((''pci: failed to configure I/O
memory on
> device ''+
>>                               ''%s -
errno=%d'')%(dev.name,rc))
>>
>> -        if not self.vm.info.is_hvm() and dev.irq:
>> +        if dev.irq > 0:
>>               rc = xc.physdev_map_pirq(domid = fe_domid,
>>                                      index = dev.irq,
>>                                      pirq  = dev.irq)
>>
>>

On 05/15/2013 08:06 AM, Jan Beulich wrote:
>>>> On 14.05.13 at 21:30, Gordan Bobic <gordan@bobich.net>
wrote:
>> Bad news, I''m afraid - I still get error "22, invalid
argument" with
>> this patch.
>
> It would of course help to know precisely where this error is being
> observed, the more that the xend change alone was reported to
> convert the original EINVAL into EEXIST in another place.
Not sure what you mean. It''s observed when running
xm start $guestname

Which logs would you like me to attach?

Gordan

>>> On 15.05.13 at 09:24, Gordan Bobic <gordan@bobich.net> wrote:
> On 05/15/2013 08:06 AM, Jan Beulich wrote:
>>>>> On 14.05.13 at 21:30, Gordan Bobic
<gordan@bobich.net> wrote:
>>> Bad news, I''m afraid - I still get error "22, invalid
argument" with
>>> this patch.
>>
>> It would of course help to know precisely where this error is being
>> observed, the more that the xend change alone was reported to
>> convert the original EINVAL into EEXIST in another place.
> 
> Not sure what you mean. It''s observed when running
> xm start $guestname
> 
> Which logs would you like me to attach?
xend.log and xend-debug.log, but ideally only the parts that in fact
relate to a run with the newly built bits (so that I won''t have to
guess
which pieces are from still running with the unpatched code).

Also, with the logs having no way for me to see that you actually
built and installed binaries with the patch in place, please double
check that you actually did (just to avoid chasing a phantom).

Jan

Thanks! I''ll give it a try in the weekend. I have been travelling,
that''s
why I haven''t pursued this further yet.

Regards,
Andreas


2013/5/14 Jan Beulich <JBeulich@suse.com>
> >>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com>
> wrote:
> > I tried adding some debugging statements in physdev_map_pirq. I have
> > attached the physdev.c with my debug statements, a hypervisor log from
> > testing, and the output of lspci -vv for my three devices.
>
> Since I didn''t hear anything from either of you anymore, I went
> through the (not very familiar to me) tool stack code again, and
> found that qemu and xend/libxl fundamentally disagree about the
> model to be used. Qemu wants to allocate PIRQs while xend/libxl
> want a 1:1 mapping. Allocating after having created a 1:1 mapping
> works by returning the 1:1 mapping as allocation result, so as long
> as libxl completes its setup before launching qemu, it would be
> obvious why things work there. Consequently I assume that xend
> launches qemu quite a bit earlier in the process of creating a new
> domain, and the result of an attempt to establish a 1:1 mapping
> when a different mapping was already established is dependent on
> the specific interrupt numbers (i.e. also explains the observations
> one of you made).
>
> Since the tool stack as a whole really ought to use a consistent
> model, and since the 1:1 mapping model for non-MSI IRQs seems
> quite natural, the below/attached patch takes care of enforcing
> a 1:1 mapping in libxc when allocation is being requested by the
> caller. Ian, Ian - do you foresee any problem with this?
>
> Please both of you give this a try and let us know of the results
> (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>
> Jan
>
> --- a/tools/libxc/xc_physdev.c
> +++ b/tools/libxc/xc_physdev.c
> @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>      map.domid = domid;
>      map.type = MAP_PIRQ_TYPE_GSI;
>      map.index = index;
> -    map.pirq = *pirq;
> +    map.pirq = *pirq < 0 ? index : *pirq;
>
>      rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map));
>
> --- a/tools/python/xen/xend/server/pciif.py
> +++ b/tools/python/xen/xend/server/pciif.py
> @@ -340,7 +340,7 @@ class PciController(DevController):
>                  raise VmError((''pci: failed to configure I/O
memory on
> device ''+
>                              ''%s -
errno=%d'')%(dev.name,rc))
>
> -        if not self.vm.info.is_hvm() and dev.irq:
> +        if dev.irq > 0:
>              rc = xc.physdev_map_pirq(domid = fe_domid,
>                                     index = dev.irq,
>                                     pirq  = dev.irq)
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 15.05.13 at 09:24, Gordan Bobic <gordan@bobich.net> wrote:
> On 05/15/2013 08:06 AM, Jan Beulich wrote:
>>>>> On 14.05.13 at 21:30, Gordan Bobic
<gordan@bobich.net> wrote:
>>> Bad news, I''m afraid - I still get error "22, invalid
argument" with
>>> this patch.
>>
>> It would of course help to know precisely where this error is being
>> observed, the more that the xend change alone was reported to
>> convert the original EINVAL into EEXIST in another place.
> 
> Not sure what you mean. It''s observed when running
> xm start $guestname
> 
> Which logs would you like me to attach?
Btw, I just took the time to figure out a way to reproduce the
original problem, and the patch I sent makes things work again
for me. So I''m suspecting you to have missed some step in the
rebuild-reinstall-restart sequence.

Let''s see what the other two reporters find once they get to
trying out that patch.

Jan

On 05/15/2013 08:50 AM, Jan Beulich wrote:
>>>> On 15.05.13 at 09:24, Gordan Bobic <gordan@bobich.net>
wrote:
>> On 05/15/2013 08:06 AM, Jan Beulich wrote:
>>>>>> On 14.05.13 at 21:30, Gordan Bobic
<gordan@bobich.net> wrote:
>>>> Bad news, I''m afraid - I still get error "22,
invalid argument" with
>>>> this patch.
>>>
>>> It would of course help to know precisely where this error is being
>>> observed, the more that the xend change alone was reported to
>>> convert the original EINVAL into EEXIST in another place.
>>
>> Not sure what you mean. It''s observed when running
>> xm start $guestname
>>
>> Which logs would you like me to attach?
>
> xend.log and xend-debug.log, but ideally only the parts that in fact
> relate to a run with the newly built bits (so that I won''t have to
guess
> which pieces are from still running with the unpatched code).
>
> Also, with the logs having no way for me to see that you actually
> built and installed binaries with the patch in place, please double
> check that you actually did (just to avoid chasing a phantom).
OK, here goes.

The 4.2.1-7 rpm I am testing against (closest to the 4.2.1-6 that works 
for me) no longer appears to be in the CRC repository here:
http://uk1.mirror.crc.id.au/repo/el6/SRPMS/

In the spec files, the patches applied are as follows:

Patch35: xend-pci-loop.patch
Patch48: qemu-xen.tradonly.patch

Patch50: xsa34-4.2.patch
Patch51: xsa35-4.2.patch
Patch52: xsa36-4.2.patch
Patch53: xsa38-v3.patch
Patch54: xsa47-4.2.patch
Patch55: xsa44-4.2.patch
Patch56: xsa46-4.2.patch
Patch57: xsa46-fix.patch

The xsa46-fix patch is the one you provided on 14/05 (two lines 
replaced, in xc_physdev_map_pirq, and one in class 
PciController(DevController).


Attached is the build log to verify that the patch was being applied.
Compressed with xz because the uncompressed file is 6.5MB.


Trying to start the domU:
# xm start edi
Error: (22, ''Invalid argument'')
Usage: xm start <DomainName>

xm debug-keys izq; xm dmesg
output attached.

xend.log and xend-debug.log also attached.

Two consecutive startups attempted, hence why there are two entries in 
the logs.

Gordan





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

On 05/16/2013 01:20 PM, Jan Beulich wrote:
>>>> On 15.05.13 at 09:24, Gordan Bobic <gordan@bobich.net>
wrote:
>> On 05/15/2013 08:06 AM, Jan Beulich wrote:
>>>>>> On 14.05.13 at 21:30, Gordan Bobic
<gordan@bobich.net> wrote:
>>>> Bad news, I''m afraid - I still get error "22,
invalid argument" with
>>>> this patch.
>>>
>>> It would of course help to know precisely where this error is being
>>> observed, the more that the xend change alone was reported to
>>> convert the original EINVAL into EEXIST in another place.
>>
>> Not sure what you mean. It''s observed when running
>> xm start $guestname
>>
>> Which logs would you like me to attach?
>
> Btw, I just took the time to figure out a way to reproduce the
> original problem, and the patch I sent makes things work again
> for me. So I''m suspecting you to have missed some step in the
> rebuild-reinstall-restart sequence.
>
> Let''s see what the other two reporters find once they get to
> trying out that patch.
I''m pretty sure I didn''t miss a step (logs attached in the
other email),
but I''m open to being proved wrong. Maybe there is a composite issue in
play.

Gordan

Now I''m happy to inform that Jan''s patch solves the problem
for me. I
patched the source version of the xen package under ubuntu12.10, currently
4.1.3-3ubuntu1.5_amd64. Now I can add pci devices any order I like.

After installing the full xen suite from the source (not knowing exactly
which packages were affected) and seeing it working, I replaced the
hypervisor package with a version with the debug changes I made earlier, to
produce the attached logs. These are xend.log and xm dmesg from the working
case, when I pass pci = [04:00.0, 41:00.0, 41:00.1] which didn''t work
before with the pre-patch code.

Thanks for this! Let me know if I should provide some more info, especially
given that this change does not yet seem to work for Gordan on 4.2.

Regards,
Andreas



2013/5/16 Andreas Falck <falck.andreas.lists@gmail.com>
> Thanks! I''ll give it a try in the weekend. I have been travelling,
that''s
> why I haven''t pursued this further yet.
>
> Regards,
> Andreas
>
>
> 2013/5/14 Jan Beulich <JBeulich@suse.com>
>
>> >>> On 05.05.13 at 21:33, Andreas Falck
<falck.andreas.lists@gmail.com>
>> wrote:
>> > I tried adding some debugging statements in physdev_map_pirq. I
have
>> > attached the physdev.c with my debug statements, a hypervisor log
from
>> > testing, and the output of lspci -vv for my three devices.
>>
>> Since I didn''t hear anything from either of you anymore, I
went
>> through the (not very familiar to me) tool stack code again, and
>> found that qemu and xend/libxl fundamentally disagree about the
>> model to be used. Qemu wants to allocate PIRQs while xend/libxl
>> want a 1:1 mapping. Allocating after having created a 1:1 mapping
>> works by returning the 1:1 mapping as allocation result, so as long
>> as libxl completes its setup before launching qemu, it would be
>> obvious why things work there. Consequently I assume that xend
>> launches qemu quite a bit earlier in the process of creating a new
>> domain, and the result of an attempt to establish a 1:1 mapping
>> when a different mapping was already established is dependent on
>> the specific interrupt numbers (i.e. also explains the observations
>> one of you made).
>>
>> Since the tool stack as a whole really ought to use a consistent
>> model, and since the 1:1 mapping model for non-MSI IRQs seems
>> quite natural, the below/attached patch takes care of enforcing
>> a 1:1 mapping in libxc when allocation is being requested by the
>> caller. Ian, Ian - do you foresee any problem with this?
>>
>> Please both of you give this a try and let us know of the results
>> (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>>
>> Jan
>>
>> --- a/tools/libxc/xc_physdev.c
>> +++ b/tools/libxc/xc_physdev.c
>> @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>>      map.domid = domid;
>>      map.type = MAP_PIRQ_TYPE_GSI;
>>      map.index = index;
>> -    map.pirq = *pirq;
>> +    map.pirq = *pirq < 0 ? index : *pirq;
>>
>>      rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map,
sizeof(map));
>>
>> --- a/tools/python/xen/xend/server/pciif.py
>> +++ b/tools/python/xen/xend/server/pciif.py
>> @@ -340,7 +340,7 @@ class PciController(DevController):
>>                  raise VmError((''pci: failed to configure I/O
memory on
>> device ''+
>>                              ''%s -
errno=%d'')%(dev.name,rc))
>>
>> -        if not self.vm.info.is_hvm() and dev.irq:
>> +        if dev.irq > 0:
>>              rc = xc.physdev_map_pirq(domid = fe_domid,
>>                                     index = dev.irq,
>>                                     pirq  = dev.irq)
>>
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

I stand corrected! Jan''s patch does in fact fix the problem. I have no 
idea what I was doing wrong, but I just tried it again (for the 4th 
time) just to make sure, uninstalled the old packages, installed the new 
ones - and now it works! There must have been a stale file somewhere 
that was breaking it.

Thanks Jan, most appreciated. :)

Gordan

On 05/19/2013 03:56 PM, Andreas Falck wrote:
> Now I''m happy to inform that Jan''s patch solves the
problem for me. I
> patched the source version of the xen package under ubuntu12.10,
> currently 4.1.3-3ubuntu1.5_amd64. Now I can add pci devices any order I
> like.
>
> After installing the full xen suite from the source (not knowing exactly
> which packages were affected) and seeing it working, I replaced the
> hypervisor package with a version with the debug changes I made earlier,
> to produce the attached logs. These are xend.log and xm dmesg from the
> working case, when I pass pci = [04:00.0, 41:00.0, 41:00.1] which
didn''t
> work before with the pre-patch code.
>
> Thanks for this! Let me know if I should provide some more info,
> especially given that this change does not yet seem to work for Gordan
> on 4.2.
>
> Regards,
> Andreas
>
>
>
> 2013/5/16 Andreas Falck <falck.andreas.lists@gmail.com
> <mailto:falck.andreas.lists@gmail.com>>
>
>     Thanks! I''ll give it a try in the weekend. I have been
travelling,
>     that''s why I haven''t pursued this further yet.
>
>     Regards,
>     Andreas
>
>
>     2013/5/14 Jan Beulich <JBeulich@suse.com
<mailto:JBeulich@suse.com>>
>
>          >>> On 05.05.13 at 21:33, Andreas Falck
>         <falck.andreas.lists@gmail.com
>         <mailto:falck.andreas.lists@gmail.com>> wrote:
>          > I tried adding some debugging statements in physdev_map_pirq.
>         I have
>          > attached the physdev.c with my debug statements, a hypervisor
>         log from
>          > testing, and the output of lspci -vv for my three devices.
>
>         Since I didn''t hear anything from either of you anymore, I
went
>         through the (not very familiar to me) tool stack code again, and
>         found that qemu and xend/libxl fundamentally disagree about the
>         model to be used. Qemu wants to allocate PIRQs while xend/libxl
>         want a 1:1 mapping. Allocating after having created a 1:1 mapping
>         works by returning the 1:1 mapping as allocation result, so as long
>         as libxl completes its setup before launching qemu, it would be
>         obvious why things work there. Consequently I assume that xend
>         launches qemu quite a bit earlier in the process of creating a new
>         domain, and the result of an attempt to establish a 1:1 mapping
>         when a different mapping was already established is dependent on
>         the specific interrupt numbers (i.e. also explains the observations
>         one of you made).
>
>         Since the tool stack as a whole really ought to use a consistent
>         model, and since the 1:1 mapping model for non-MSI IRQs seems
>         quite natural, the below/attached patch takes care of enforcing
>         a 1:1 mapping in libxc when allocation is being requested by the
>         caller. Ian, Ian - do you foresee any problem with this?
>
>         Please both of you give this a try and let us know of the results
>         (patch applies cleanly to all of -unstable, 4.2, and 4.1).
>
>         Jan
>
>         --- a/tools/libxc/xc_physdev.c
>         +++ b/tools/libxc/xc_physdev.c
>         @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
>               map.domid = domid;
>               map.type = MAP_PIRQ_TYPE_GSI;
>               map.index = index;
>         -    map.pirq = *pirq;
>         +    map.pirq = *pirq < 0 ? index : *pirq;
>
>               rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map,
>         sizeof(map));
>
>         --- a/tools/python/xen/xend/server/pciif.py
>         +++ b/tools/python/xen/xend/server/pciif.py
>         @@ -340,7 +340,7 @@ class PciController(DevController):
>                           raise VmError((''pci: failed to configure
I/O
>         memory on device ''+
>                                       ''%s -
errno=%d'')%(dev.name
>         <http://dev.name>,rc))
>
>         -        if not self.vm.info.is_hvm() and dev.irq:
>         +        if dev.irq > 0:
>                       rc = xc.physdev_map_pirq(domid = fe_domid,
>                                              index = dev.irq,
>                                              pirq  = dev.irq)
>
>
>
>

On 20/05/2013 5:59 AM, Gordan Bobic wrote:
> I stand corrected! Jan''s patch does in fact fix the problem. I
have no
> idea what I was doing wrong, but I just tried it again (for the 4th
> time) just to make sure, uninstalled the old packages, installed the new
> ones - and now it works! There must have been a stale file somewhere
> that was breaking it.
>
> Thanks Jan, most appreciated. :)
This is great news...

Jan / Ian / Andrew:

What is the path forward for this now? Will it just be committed then 
included in 4.2.3 or 4.1.x? I''m just trying to figure out if this will 
be the official fix or something else will happen before I start rolling 
new packages with this fix applied for distribution...

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

On 20/05/13 01:50, Steven Haigh wrote:
> On 20/05/2013 5:59 AM, Gordan Bobic wrote:
>> I stand corrected! Jan''s patch does in fact fix the problem. I
have no
>> idea what I was doing wrong, but I just tried it again (for the 4th
>> time) just to make sure, uninstalled the old packages, installed the
new
>> ones - and now it works! There must have been a stale file somewhere
>> that was breaking it.
>>
>> Thanks Jan, most appreciated. :)
> This is great news...
>
> Jan / Ian / Andrew:
>
> What is the path forward for this now? Will it just be committed then 
> included in 4.2.3 or 4.1.x? I''m just trying to figure out if this
will
> be the official fix or something else will happen before I start rolling 
> new packages with this fix applied for distribution...
>
It looks to me like a good fix.  It is however a libxc bugfix so is at
the discretion of the tools maintainers.

~Andrew

On Mon, 2013-05-20 at 09:55 +0100, Andrew Cooper wrote:
> On 20/05/13 01:50, Steven Haigh wrote:
> > On 20/05/2013 5:59 AM, Gordan Bobic wrote:
> >> I stand corrected! Jan''s patch does in fact fix the
problem. I have no
> >> idea what I was doing wrong, but I just tried it again (for the
4th
> >> time) just to make sure, uninstalled the old packages, installed
the new
> >> ones - and now it works! There must have been a stale file
somewhere
> >> that was breaking it.
> >>
> >> Thanks Jan, most appreciated. :)
> > This is great news...
> >
> > Jan / Ian / Andrew:
> >
> > What is the path forward for this now? Will it just be committed then 
> > included in 4.2.3 or 4.1.x? I''m just trying to figure out if
this will
> > be the official fix or something else will happen before I start
rolling
> > new packages with this fix applied for distribution...
> >
> 
> It looks to me like a good fix.  It is however a libxc bugfix so is at
> the discretion of the tools maintainers.
I suppose someone (Jan I guess) is going to repost it with an
appropriate subject line, S-o-b, Tested-by, etc?

Ian.

>>> On 20.05.13 at 11:13, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Mon, 2013-05-20 at 09:55 +0100, Andrew Cooper wrote:
>> On 20/05/13 01:50, Steven Haigh wrote:
>> > On 20/05/2013 5:59 AM, Gordan Bobic wrote:
>> >> I stand corrected! Jan''s patch does in fact fix the
problem. I have no
>> >> idea what I was doing wrong, but I just tried it again (for
the 4th
>> >> time) just to make sure, uninstalled the old packages,
installed the new
>> >> ones - and now it works! There must have been a stale file
somewhere
>> >> that was breaking it.
>> >>
>> >> Thanks Jan, most appreciated. :)
>> > This is great news...
>> >
>> > Jan / Ian / Andrew:
>> >
>> > What is the path forward for this now? Will it just be committed
then
>> > included in 4.2.3 or 4.1.x? I''m just trying to figure out
if this will
>> > be the official fix or something else will happen before I start
rolling
>> > new packages with this fix applied for distribution...
>> >
>> 
>> It looks to me like a good fix.  It is however a libxc bugfix so is at
>> the discretion of the tools maintainers.
> 
> I suppose someone (Jan I guess) is going to repost it with an
> appropriate subject line, S-o-b, Tested-by, etc?
Sure - I''m in the process of doing so.

Jan