search for: include_all

...1); dev_scope_end = ((void *)drhd) + header->length; ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - dmaru, DMAR_TYPE, drhd->segment); + &dmaru->scope, DMAR_TYPE, drhd->segment); if ( dmaru->include_all ) { @@ -590,7 +588,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_hea dev_scope_start = (void *)(rmrr + 1); dev_scope_end = ((void *)rmrr) + header->length; ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end, - rmrru, RMRR_TYPE, rmrr->segm...

Xen 3.4 xen-unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create

...uct virtio_iommu_topo_endpoint ep; > +}; > + > +struct viommu_spec { > + struct device *dev; /* transport device */ > + struct fwnode_handle *fwnode; > + struct iommu_ops *ops; > + struct list_head list; > + size_t num_items; Intel DMAR allows an IOMMU to claim INCLUDE_ALL thus avoid listing every endpoint one-by-one. It is especially useful when there is only one IOMMU device in the system. Do you think whether making sense to allow such optimization in this spec? It doesn't work for ARM since you need ID mapping to find the MSI doorbell. But for architectures w...

The patches are as follows: Patch 1: Map RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Patch 2: There is only one INCLUDE_ALL DMAR unit in system, but no restriction on whether it''s the last unit. Patch 3: Change code style of pci.c file, and add spin_unlock(&pdev->lock) when iommu_add_device() fails. Patch 4: Add put_domain() for breaks in arch_do_domctl(). Signed-off-by: Weidong Han <weidong.han@inte...

...413:   dmaru->address = fbffe000 (XEN) [VT-D]iommu.c:1122: drhd->address = fbffe000 iommu->reg = ffff82c3fff56000 (XEN) [VT-D]iommu.c:1124: cap = c90780106f0462 ecap = f020fe (XEN) [VT-D]dmar.c:356:   IOAPIC: f0:1f.7 (XEN) [VT-D]dmar.c:356:   IOAPIC: 0:13.0 (XEN) [VT-D]dmar.c:427:   flags: INCLUDE_ALL (XEN) [VT-D]dmar.c:724: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:341:   endpoint: 0:1d.0 (XEN) [VT-D]dmar.c:341:   endpoint: 0:1d.1 (XEN) [VT-D]dmar.c:341:   endpoint: 0:1d.2 (XEN) [VT-D]dmar.c:341:   endpoint: 0:1d.7 (XEN) [VT-D]dmar.c:341:   endpoint: 0:1a.0 (XEN) [VT-D]dmar.c:341:   endpoint: 0:...

Hello, I''m also seeing this exact same problem. I''ve posted on xen-users, but did not get an answer. Venkat seems to be experiencing the same problem as me. I have the latest BIOS for my motherboard DQ35JO. (BIOS ver 933) I''m running a Q6600 as well. It hangs at "Brought up 4 CPUs." I''ve tried all sorts of combinations of Xen versions and kernels to

Hello, I''ve previously been successful with Xen4 and VT-d on other systems. I am having trouble getting VT-d passthrough working to a WinXP domain with DX58SO (Q45) motherboard and i7 930 CPU. VT-d is enabled in bios, xm info shows hvm_directio capability, I have iommu=1 set, I have the devices bound to pciback on dom0 cmdline, xm pci-list-assignable-devices shows the devices as

Hello, I''ve previously been successful with Xen4 and VT-d on other systems. I am having trouble getting VT-d passthrough working to a WinXP domain with DX58SO (Q45) motherboard and i7 930 CPU. VT-d is enabled in bios, xm info shows hvm_directio capability, I have iommu=1 set, I have the devices bound to pciback on dom0 cmdline, xm pci-list-assignable-devices shows the devices as

...34: endpoint: 0:1b.0 (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:398: dmaru->address = fed91000 (XEN) [VT-D]dmar.c:334: endpoint: 0:2.0 (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:398: dmaru->address = fed93000 (XEN) [VT-D]dmar.c:411: flags: INCLUDE_ALL (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:334: endpoint: 0:1d.0 (XEN) [VT-D]dmar.c:334: endpoint: 0:1a.0 (XEN) [VT-D]dmar.c:571: RMRR region: base_addr bb6e9000 end_address bb6fffff (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:334: endpoint: 0:2.0...

...ress = fedb0000 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:3.0 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:3.2 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:3.3 (XEN) [VT-D]dmar.c:469: found ACPI_DMAR_DRHD (XEN) [VT-D]dmar.c:337: dmaru->address = fedb1000 (XEN) [VT-D]dmar.c:346: found INCLUDE_ALL (XEN) [VT-D]dmar.c:473: found ACPI_DMAR_RMRR (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.0 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.1 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.2 (XEN) [VT-D]dmar.c:288: found endpoint: bdf = 0:1d.7 (XEN) [VT-D]dmar.c:288: found endpoint: bd...

Hello, I''m having problems with VTD on this board. The board/cpu/bios all support vt-d and I think maybe I''m just missing something? Any feedback would be much appreciated :) Output below: root@vm:~# xm create /etc/xen/vm-nine.cfg Using config file "/etc/xen/vm-nine.cfg". Error: Failed to assign device to IOMMU (0000:05:00.0@100,msitranslate=1,power_mgmt=0)

Hello, I''m having problems with VTD on this board. The board/cpu/bios all support vt-d and I think maybe I''m just missing something? Any feedback would be much appreciated :) Output below: root@vm:~# xm create /etc/xen/vm-nine.cfg Using config file "/etc/xen/vm-nine.cfg". Error: Failed to assign device to IOMMU (0000:05:00.0@100,msitranslate=1,power_mgmt=0)

I try pci pci passthrough with xen 3.3.1 and CentOS 5.2(64bit) on a SUPERMICRO C7X58 board I see the following the error in my boot log. (XEN) [VT-D]dmar.c:372: RMRR is incorrect. This problem is caused by this condition in dmr.c:372. if ( rmrr->base_address >= rmrr->end_address ) { dprintk(XENLOG_ERR VTDPREFIX, "RMRR is incorrect.\n"); return -EFAULT; } As an

I try pci pci passthrough with xen 3.3.1 and CentOS 5.2(64bit) on a SUPERMICRO C7X58 board I see the following the error in my boot log. (XEN) [VT-D]dmar.c:372: RMRR is incorrect. This problem is caused by this condition in dmr.c:372. if ( rmrr->base_address >= rmrr->end_address ) { dprintk(XENLOG_ERR VTDPREFIX, "RMRR is incorrect.\n"); return -EFAULT; } As an