similar to: [PATCH] fix memory allocation from NUMA node for VT-d.

On Xen-3.3.0, domain0 Megaraid SAS (SAS 1068 controller) driver is not loading correctly if vtd support in Xen is enabled. It fails at the point of initializing firmware. I wasn''t seeing this error with Xen-3.2.2-rc3 (Unstable version), though with vtd disabled in Xen-3.3.0, it is working. Looks like a degrade problem. Any clues? Thx, Venkat

Hi, all, The attached patches try to improve the current FLR logic. The idea is: removing the FLR logic from hypervisor and adding the improved logic in Control Panel. The current FLR logic in hypervisor has some issues: 1) Dstate transition is not guaranteed to properly clear the device state; 2) the current code for PCIe FLR is actually buggy: PCI_EXP_DEVSTA_TRPND doesn''t mean the

On map: only flush when old PTE was valid or invalid PTE may be cached. On unmap: always flush old entry, but skip flush for unaffected IOMMUs. Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com> -- iommu.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- diff -r 8187fd8113f9 xen/drivers/passthrough/vtd/iommu.c ---

Hi, I''ve added some preliminary support for VT-d for paravirtualized guests. This must be enabled using an ''iommu_pv'' boot parameter (disabled by default). I''ve added some python bindigs to allow xend to assign PCI devices to IOMMU for PV guests. For HVM guests this is handled in ioemu. Not sure if it makes sense to handle both cases in one place. The

Hi, Keir, This patch will move reading and writing of PCI configuration spaces from dom0 to Xen. It also changes VTD code, so that they can touch the PCI configuration spaces with proper lock. This will also benefit MSI support in Xen. Can you give some comments? Thanks! <<pci_conf_xen.patch>> Best Regards Haitao Shan _______________________________________________ Xen-devel

Fixes made in version 2: 1) Use PML4[257] for ioremap of PCI mmcfg. As full 16-bit segment support would require 44-bits. Since each slot only has 39-bits, we support 2048 PCI segments for now. This can be easily expanded if deemed necessary in the future. 2) Integrated PCI mmcfg access with existing PCI config interface for x86_64. Use MMCFG interface if offset is greater than 256.

I am submitting the patch which supports more Capability Structures and Device Specific Registers for passthrough device. In Xen 3.3 unstable, qemu-dm supports Configuration Header, MSI Capability Structure, and MSI-X Capability Structure. But qemu-dm does not support PCI Express Capability Structure, Device Specific Registers, etc (writing them is ignored). To support various I/O devices, I

On 32e, we create one guest, then hotplug attach one NIC to guest, guest can not get IP address via dhcp, guest qemu log shows "libpci read error. No emulation ". Here is the bug entry: One 32e, hotplug attaching VT-d NIC to guest failed. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1316. -- haicheng _______________________________________________ Xen-devel mailing list

I assigned FC-HBA to guest domain, but it did not work. FC-HBA seems to write its internal memory which is mapped to host memory space via pci transaction. But there is no mapping in IOMMU''s page table, so that page fault occurs in IOMMU. I think that MMIO resource mapped via p2m table should be mapped via IOMMU''s page table too. In other word, XEN_DOMCTL_memory_mapping

This patch adds the function that reassign page-aligned memory resources, to dom0 linux. The function is useful when we assign I/O device to HVM domain using pci passthrough. When we assign a device to HVM domain using pci passthrough, the device needs to be assigned page-aligned memory resources. If the memory resource is not page-aligned, following error occurs. Error: pci: 0000:00:1d.7:

Hi, Keir, These patches are rebased version of Yunhong''s original patches, which were sent out before XEN 3.2 was released. These patches enable MSI support and limited MSI-X support in XEN. Here is the original description of the patches from Yunhong''s mail. The basic idea including: 1) Keep vector global resource owned by xen, while split pirq into per-domain

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

According to vt-d specs, the addr in IOTLB invalidation descriptor should be 4K page aligned. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> diff -r 0455d8317631 xen/drivers/passthrough/vtd/qinval.c --- a/xen/drivers/passthrough/vtd/qinval.c Thu Jun 28 18:43:28 2012 +0100 +++ b/xen/drivers/passthrough/vtd/qinval.c Wed Jul 11 08:43:24 2012 +0800 @@ -140,7 +140,7 @@ static int

Hi, The staging tree 19185:1eb6afcad849 cannot be compiled on ia64: vtd.c: In function `alloc_pgtable_maddr'': vtd.c:60: error: too few arguments to function `iommu_flush_cache_page'' The attached patch fixes it. Signed-off-by: KUWAMURA Shin''ya <kuwa@jp.fujitsu.com> Best regards, -- KUWAMURA Shin''ya

hi, I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR. DMAR @ 0x7fef1000 0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL 0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT 0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#...........

Detect invalid/unsupported configurations in iommu_alloc() - offsets read from hardware must not lead to exceeding a single page (since only that much gets mapped). This covers the apparently not uncommon case of the address pointed to by a DMAR reading as all ones (Linux for example also checks for this). Further correct error handling of that function: Without storing the allocated "struct

Compilation failure on c/s 17194 is as follows: /root/randy/vtd-stage/xen/common/built_in.o: In function `guest_remove_page'': /root/randy/vtd-stage/xen/common/memory.c:172: undefined reference to `__bitop_bad_size'' /root/randy/vtd-stage/xen/common/memory.c:172: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__bitop_bad_size''

Hi all, This is today''s xen nightly test report, changeset: 16481 unstable tree.  Linux-xen:323 No new issue today. But I include full validation failure in this list.    Old issues : ================================================= 1) Can not install 32bit Fedora 7 with vcpu > 1 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1084 2) [Installation] Fedora8 IA32e guest

Hi All, There are two new issues found in Xen 3.2 RC2 compared with last time nightly testing. Save/Restore failed and local live migration failed. There is also another installation issue found in regular testing: HVM domain would be blue scree when install 32bit up acpi winXP on 32e host It is reported in HVM domain, if using SCSI emulation (disk = [

diff -r e6266fc76d08 -r 6feac926cf80 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Fri Jul 27 12:22:13 2012 +0200 +++ b/xen/drivers/passthrough/vtd/iommu.c Mon Jul 30 15:35:16 2012 -0700 @@ -2137,6 +2137,15 @@ int __init intel_vtd_setup(void) { iommu = drhd->iommu; + printk("Intel VT-d supported page sizes: 4kB"); + if