search for: pciif

...XendDomainInfo:815) pci: assign device 0000:00:02.0@10,msitranslate=1,power_mgmt=0 [2011-05-24 16:02:04 2335] DEBUG (image:508) signalDeviceModel: orig_state is None, retrying [2011-05-24 16:02:05 2335] INFO (image:538) signalDeviceModel:restore dm state to running [2011-05-24 16:02:05 2335] DEBUG (pciif:320) pci: enabling ioport 0xf160/0x8 [2011-05-24 16:02:05 2335] DEBUG (pciif:334) pci: enabling iomem 0xfe000000/0x400000 pfn 0xfe000/0x400 [2011-05-24 16:02:05 2335] DEBUG (pciif:334) pci: enabling iomem 0xd0000000/0x10000000 pfn 0xd0000/0x10000 [2011-05-24 16:02:05 2335] DEBUG (pciif:351) pci: en...

...o /local/domain/0/backend/tap/6/51712. [2007-12-13 17:26:20 xend 8789] INFO (pciquirk:91) NO quirks found for PCI device [1166:024b:1028:0205] [2007-12-13 17:26:20 xend 8789] DEBUG (pciquirk:131) Permissive mode NOT enabled for PCI device [1166:024b:1028:0205] [2007-12-13 17:26:20 xend 8789] DEBUG (pciif:159) pci: enabling ioport 0xecb0/0x8 [2007-12-13 17:26:20 xend.XendDomainInfo 8789] ERROR (XendDomainInfo:212) Domain construction failed Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 205, in create vm.initDomain() Fi...

The hypervisor side changes for XSA-46 require the tool stack to now always map the guest pIRQ before granting access permission to the underlying host IRQ (GSI). This in particular requires that pciif.py no longer can skip this step (assuming qemu would do it) for HVM guests. This in turn exposes, however, an inconsistency between xend and qemu: The former wants to always establish 1:1 mappings between pIRQ and host IRQ (for non-MSI only of course), while the latter always wants to allocate an...

...e SXP''s. In most cases, the SXP looks # like this: # # [device, [vif, [mac, xx:xx:xx:xx:xx:xx], [ip 1.3.4.5]]] # # However, for PCI devices it looks like this: # # [device, [pci, [dev, [domain, 0], [bus, 0], [slot, 1]]]] # # It seems the reasoning for this difference is because # pciif.py needs all the PCI device configurations at # the same time when creating the devices. So multiple pci devices sit in one single config entry with single uuid(see following configs), which make device handling difficult(consider if support hotplug). Can anybody explain why pciif.py needs all...

...;'e4b1c87e-663e-658c-b352-83fecb702ab9''} [2009-05-04 09:46:50 2332] INFO (pciquirk:90) NO quirks found for PCI device [1095:3114:1095:3114] [2009-05-04 09:46:50 2332] DEBUG (pciquirk:132) Permissive mode NOT enabled for PCI device [1095:3114:1095:3114] [2009-05-04 09:46:50 2332] DEBUG (pciif:153) pci: enabling ioport 0x3048/0x8 [2009-05-04 09:46:50 2332] DEBUG (pciif:153) pci: enabling ioport 0x303c/0x4 [2009-05-04 09:46:50 2332] DEBUG (pciif:153) pci: enabling ioport 0x3040/0x8 [2009-05-04 09:46:50 2332] DEBUG (pciif:153) pci: enabling ioport 0x3038/0x4 [2009-05-04 09:46:50 2332] DEBU...

Hi, I tried to attach passrough io device to domU, the command (ended successfully in dom0), but when I entered the domU and typed the "lspci" command I didn''t see the new device, although the dom0 removed it from the "pci-list-assignable-devices". When I tried to detach it from the domU, the detach command returned with timeout error. What did I miss? perhaps I

..._poweroff = 'destroy' on_reboot = 'destroy' on_crash = 'destroy' --------- Of course the devices are assignable: --------- # xm pci-list-assignable-devices 0000:00:02.0 0000:00:1b.0 0000:00:1d.0 --------- In the xend.log it says: --------- [2013-05-01 11:10:29 4897] DEBUG (pciif:320) pci: enabling ioport 0xf000/0x40 [2013-05-01 11:10:29 4897] DEBUG (pciif:334) pci: enabling iomem 0xf7800000/0x400000 pfn 0xf7800/0x400 [2013-05-01 11:10:29 4897] DEBUG (pciif:334) pci: enabling iomem 0xe0000000/0x10000000 pfn 0xe0000/0x10000 [2013-05-01 11:10:29 4897] DEBUG (pciif:351) pci: e...

...? from xen.xend.XendConfig import XendConfig File "//usr/lib/python/xen/xend/XendConfig.py", line 27, in ? from xen.xend.XendDevices import XendDevices File "//usr/lib/python/xen/xend/XendDevices.py", line 22, in ? from xen.xend.server import blkif, netif, tpmif, pciif, iopif, irqif, usbif, vfbif File "//usr/lib/python/xen/xend/server/pciif.py", line 38, in ? xc = xen.lowlevel.xc.xc() xen.lowlevel.xc.Error: (1, ''Internal error'', ''Could not obtain handle on privileged command interface (2 = No such file or directory)'...

I think we need this feature at least for debugging purpose, right? Or, do we already have this feature? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...ot;" Perform FLR (Functional Level Reset) for the device. """ + return if self.dev_type == DEV_TYPE_PCIe_ENDPOINT: # If PCIe device supports FLR, we use it. if self.pcie_flr: diff -r 6ab55f716ce3 tools/python/xen/xend/server/pciif.py --- a/tools/python/xen/xend/server/pciif.py Thu Oct 09 17:18:11 2008 +0100 +++ b/tools/python/xen/xend/server/pciif.py Fri Oct 10 13:18:25 2008 +0800 @@ -375,6 +375,7 @@ class PciController(DevController): pci_dev_list = pci_dev_list + [(domain, bus, slot, func)] for (do...

Hi all, I downloaded the xen 3.3.0 and now testing the pci pass-through with the NIC. Using late binding, the pci slot 0000:08:01.0 is assigned to pciback. But pci related xm commands are not working. For eg: linux-242:/home/xen-3.3.0 # xm pci-list-assignable-devices Unexpected error: <type ''exceptions.OSError''> Please report to

...XendDomainInfo.py", line 1891, in _createDevice return self.getDeviceController(deviceClass).createDevice(devConfig) File "//usr/lib64/python/xen/xend/server/DevController.py", line 94, in createDevice self.setupDevice(config) File "//usr/lib64/python/xen/xend/server/pciif.py", line 432, in setupDevice self.setupOneDevice(domain, bus, slot, func) File "//usr/lib64/python/xen/xend/server/pciif.py", line 289, in setupOneDevice raise VmError("pci: %s: non-page-aligned MMIO BAR found." % dev.name) VmError: pci: 0000:10:0a.0: non-page-al...

...em supports Function Level Reset (FLR), see http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00626.html. Your cards probably are behind the same PCI bridge. If you don''t care about the FLR functionality, then you could remove the checks for this in tools/python/xen/xend/server/pciif.py - you just need to recompile the Xen tools in Dom0, but no kernel changes. This is a hack though rather than a good solution :( I am not sure if there are any other drawbacks for doing this. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com htt...

...atch: make some small fix in aerdrv_core, adding helper function for searching pci_dev by BDF Patch 6 pciback_err_handler.patch: main implementation for XEN AER handling support, adding related pci error handler in pciback and pcifront. Patch 7 pcifront_err_handler.patch: related interface changes (pciif.h) in XEN header file. Also add domain shutdown support in xend for shutting domain from DOM0 kernel. Thanks& Regards, Criping _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

On Wed, Jan 27, 2016 at 7:30 PM, Konrad Rzeszutek Wilk < konrad.wilk at oracle.com> wrote: > On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote: > > Xen developers, > > > > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed > > NIC stopped working. > > This bug was probably introduced in Debian Jessie sometime > > between

Following 7 patches are for PCIE AER (Advanced Error Reporting) support for XEN. --------------------------------------------------------------------------- Patches 1~4 back port from Linux Kernel which enables kernel support to AER. Those patches enable DOM0 PCIE error handling capability. When a device sends a PCIE error message to the root port, it will trigger an interrupt. The irq handler

...DomainInfo.py", line 1869, in _createDevice return self.getDeviceController(deviceClass).createDevice(devConfig) File "//usr/lib64/python/xen/xend/server/DevController.py", line 94, in createDevice self.setupDevice(config) File "//usr/lib64/python/xen/xend/server/pciif.py", line 415, in setupDevice devs_str = dev.find_coassigned_devices(True) File "//usr/lib64/python/xen/util/pci.py", line 460, in find_coassigned_devices dev = self.find_the_uppermost_pci_bridge() File "//usr/lib64/python/xen/util/pci.py", line 423, in find...

...r - Example xend HTTP xen.xend.server.SrvVnetDir xen.xend.server.SrvXendLog xen.xend.server.XMLRPCServer xen.xend.server (package) xen.xend.server.blkif xen.xend.server.iopif xen.xend.server.irqif xen.xend.server.netif - Support for virtual network interfaces. xen.xend.server.params xen.xend.server.pciif xen.xend.server.pciquirk xen.xend.server.relocate xen.xend.server.tests (package) xen.xend.server.tests.test_controllers xen.xend.server.tpmif - Support for virtual TPM interfaces. xen.xend.server.usbif - Support for virtual USB hubs. xen.xend.server.vfbif xen.xend.sxp - Input-driven parsing for s-...

There is a BUG_ON() at xen/arch/x86/physdev.c:169 which appears to be dependent upon guest behavior (should close event channel before un-mapping pirq), rather than on internal hypervisor state. In 2.6.18, this likely goes unnoticed because pci_device_shutdown() only calls all the driver shutdown routines. In newer kernels, however, it also calls pci_msi_shutdown() and pci_msix_shutdown(), which

Hi, I''m trying to get VGA passthrough to work to an XP x64 guest, and I''m seeing "interesting" things happening. I''m using the kernel and userspace tools from here: http://xen.crc.id.au/support/guides/install/# on Scientific Linux 6. I gave up on trying to get an Nvidia card to work in the guest having read about the extra patches required to get a