similar to: [PATCH 2/2][VTD] ats support for Intel64 with VT-d

Pass gfx_passthru parameter to QEMU. Keep it boolean for now as QEMU does not expect any other integer value. Signed-off-by: Allen Kay <allen.m.kay@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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.

Now if VT-d is enabled, when Dom0 does S3, Xen doesn''t suspend/resume the IOMMU states. The patch adds the missing invocations of iommu_suspend()/iommu_resume() and makes some nesessary fixes: 1) In iommu_set_root_entry(), we should not re-allocate the root-entry when Xen returns from S3; 2) Define the array iommu_state correctly (u8 -> u32); 3) Only save/restore the necessary IOMMU

The following 5 patches are re-submissions of the vt-d patch. This set of patches has been tested against cs# 15080 and is now much more mature and tested against more environments than the original patch. Specifically, we have successfully tested the patch with following environements: - 32/64-bit Linux HVM guest - 32-bit Windows XP/Vista (64-bit should work but did not test) -

The memory relating guest domain should be allocated from NUMA node on which the guest runs. Because the latency of the same NUMA node is faster than that of a different one. This patch fixes memory allocation for Address Translation Structure of VT-d. VT-d uses two types of Structures for DMA address translation. The one is Device Assignment Structure. The other is Address Translation

All, We met several system failures on different hardware platforms, which are all caused by VT-d fault. err 1: disk is corrupted by VT-d fault on SATA. err 2: Dom0 kernel panics at booting, which is caused VT-d fault on UHCI. err 3, Dom0 complains disk errors while creating HVM guests. The culprit would be changeset 19054 "x86_64: Remove statically-partitioned Xen heap.". Detailed

Hi Tim, Could you please have a look at this bug? Thanks a lot. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774 Best Regards, Yongjie Ren (Jay) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Keir, It''s a resending patch for the timeout mechanism to deal with the shared interrupt issue for vt-d enabled hvm guest. We modify the patch following your comments last time and make some other small fix: 1) We don''t touch the locking around the hvm_dpci_eoi(). 2) Remove the HZ from the TIME_OUT_PERIOD macro which may confuse others. 3) Add some

Trying to set up PCI pass through with xen 3.2.1 on Debian Lenny, with xen Kernel 2.6.26... having no luck. I have the following configured... i) Virtualization and vt-d are both enabled in the bios, I have power cycled after making these changes. ii) I have these option in grub menu; iommu=1 pciback.permissive pciback.hide=(07:01.0)(01:00.0) vtd=1 iii) I have this in my cfg file

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

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 all, Thought I''d share my success with VT-d. I picked up an Asus P5E-VM DO motherboard as it was relatively cheap and had an extra PCI slot compared to the Intel Q35 board. The people on #xen IRC were very helpful. I wasted 2 days trying to get things working on Ubuntu and OpenSUSE with forward patched versions of Xen for newer kernels. Ended up using CentOS 5.1 which has the requred

Hi, I''ve recently setup a few machines with 3.2 64bit without any unresolvable problem. These machines all run pv domU''s and a view "basic" hvm domUs. As I''ve got one machine left for internal use and testing, I would like to take a look at pciback with VT-d support (bios screen shows a VT-d [enable|disable]). My question is, do I need to add patches, or use

Hi, I''ve recently setup a few machines with 3.2 64bit without any unresolvable problem. These machines all run pv domU''s and a view "basic" hvm domUs. As I''ve got one machine left for internal use and testing, I would like to take a look at pciback with VT-d support (bios screen shows a VT-d [enable|disable]). My question is, do I need to add patches, or use

Attached is a patch for shared interrupt between dom0 and HVM domain for vtd. Most of problem is caused by that we should inject interrupt to both domains and the physical interrupt deassertion then may be delayed by the device assigned to the HVM. The patch adds a timer, and the time out value is sufficient large to tolerant the delaying used to wait for the physical interrupt deassertion.

After building Xen-3.2.1 I could successfully boot into it if I avoid giving vtd=1 as the boot parameter. If I pass vtd=1 as the boot parameter to xen, the system hangs while booting. The system hangs after the following messages ============================ Boot messages [XEN]..... [Xen] Brought up 2 CPUs... ========================= My chipset DQ35 series is having VT-d support and is enabled in

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

Hello all, please tell me, how can I be sure that my Xen installation is built with Intel VT-d support? Something like xm info | grep -i KEY-REGULAR-EXPRESSION xm dmesg | grep -i KEY-REGULAR-EXPRESSION What a line should I look for? And if my installation was really built with VT-d support, how can I be sure, that Xen has successfully initialized VT-d hardware? I have read [1] and the

lspci -vvv and -t attached Serial console output: http://pastebin.ca/2177395 Main error appears to be: (XEN) [VT-D]iommu.c:858: iommu_fault_status: Primary Pending Fault (XEN) [VT-D]iommu.c:833: DMAR:[DMA Read] Request device [00:1e.0] fault addr df8e5000, iommu reg = ffff82c3fff57000 (XEN) DMAR:[fault reason 06h] PTE Read access is not set onboard nic on the same bus is going

Hi list, I have a problem with a new laptop (reproducable on other machines too) and the xen hypervisor. When the hypervisor gets booted with VESA mode 800x600 I see some messages and then the screen contents is switched into a pattern of vertical colored lines and never comes back. In text mode all works well, but later the pattern appears when the X servers starts. I disabled VTd in the bios