similar to: [VTD][patch 0/5] HVM device assignment using vt-d

int.patch: - Supports only level-triggered interrupts. Edge interrupts support will be added shortly (should be fairly simple) - Change polarity trick: in order to reflect the external device''s assertion state, the ioapic pin gets its polarity changed whenever an interrupt occur. So an interrupt is generated when the _external_ line is asserted (then,

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.

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

This patch applies to c/s #15522. Nativedom 1:1 memory enabling - Done by "stealing" memory from Xen''s e820 at boot time. The pages are later being allocated to NativeDom using a special allocator. x86-64 ====== The 512KB-1MB region is remapped (because of the ROMs) to an address above 16MB. As far as NativeDom can see: 1. The 0-512KB

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

Recently our automated testing system has caught a curious assertion while testing Xen 4.1.5 on a HaswellDT system. (XEN) Assertion ''(sp == 0) || (peoi[sp-1].vector < vector)'' failed at irq.c:1030 (XEN) ----[ Xen-4.1.5 x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82c48016b2b4>] do_IRQ+0x514/0x750 (XEN) RFLAGS: 0000000000010093 CONTEXT:

Signed-off-by Kevin Tian <kevin.tian@intel.com> Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Maybe it''s a dumb question, but I''m actually trying to understand how the memory allocation works within Xen. I try to give 128MB to a domU and see if it increases for example when I "nano" a 500mb file, but the process just get killed when it reachs the 128MB memory limit. How do I configure the guests so they can ask for more memory until a limit is reached

From: Yang Zhang <yang.z.zhang@Intel.com> The follwoing patches are adding the Posted Interrupt supporting to Xen: Posted Interrupt allows vAPIC interrupts to inject into guest directly without any vmexit. - When delivering a interrupt to guest, if target vcpu is running, update Posted-interrupt requests bitmap and send a notification event to the vcpu. Then the vcpu will handle this

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Hi, Can anybody shed light on the Xen function map_domain_page (in xen/arch/x86/x86_32/domain_page.c)? What is it doing? Jinpeng Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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, I saw that Xen support a translation between device/intx to GSI for a single PCI bus, I thought about adding multiple PCI bus support but disregard the bus information so the same device/intx on different buses will be OR wired to the same GSI, sounds reasonable? What other things do I need to support in Xen in order to add multiple PCI buses, assuming that secondary buses holds only

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

This patch implements cpu offline feature. Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

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.

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

Folks, I download the Neocleus 1:1 patch from following link: http://lists.xensource.com/archives/html/xen-devel/2007-05/msg01144.html Currently I want to add Neocleus 1:1 Patch to the xen-3.1.0 to make the HVM guest grab the device directly. When I add these patches and recompile and install the Xen source and try to start the HVM guest, the HVM guest can not start and the system hang.

Ever since 3.0.2 we''ve been carrying this patch in our products. Since there was no indication that there would be anything wrong with the ''new'' IO-APIC ack method added back then, we finally decided to drop this patch recently from SLE11, to find that the subsequent release candidate failed to work on at least on system without using "ioapic_ack=old". With