similar to: AMD IOMMU intremap tables and IOAPICs

Dear mailinglist, I own a Gigabyte motherboard GA 970A UD3 with IOMMU support. Since the update XSA-36 (also part of the latest debian wheezy pkg), the IO-Virtualisation does not work any more as discussed on this mailinglist [0] and [1]. I like to ask, if there is an "official" solution in sight. I''m not sure about my alternatives. How "dangerous" is the

Hi! From other people posting to this list, I know that there has been a bug related to the issue described in Xen Security Advisory 36 that disables iommu for some AMD users like me. However, even when passing "iommu=no-amd-iommu-perdev-intremap" it still disables i/o virtualisatoin. Related Xen dmesg output: (XEN) IVHD Error: Invalid IO-APIC 0 (XEN) AMD-Vi: Error initialization

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) -

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:

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

Greetings, I''m attempting to do gfx_passthru with the primary graphics adapter (03:00.0), passing it to a guest. I can unbind it from the host but when I fire up the guest OS my monitor loses signal from the graphics card and that''s that. The GFX card is dual DVI, I''ve tried both slots. Host is Linux 2.6.32.14-1.2.105.xendom0.fc12.x86_64, Guest is Windows 7. PC is an

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called as introduced with the patch "x86-64: detect processors subject to AMD erratum #121 and

http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html Stepping B-3 has two errata (#47 and #53) related to Interrupt remapping, to which the workaround is for the BIOS to completely disable interrupt remapping. These errata are fixed in stepping C-2. Unfortunately this chipset is very common and many BIOSes are not disabling remapping. We can

This patchset implements the KVM part of the synthetic interrupt controller (SynIC) which is a building block of the Hyper-V paravirtualized device bus (vmbus). SynIC is a lapic extension, which is controlled via MSRs and maintains for each vCPU - 16 synthetic interrupt "lines" (SINT's); each can be configured to trigger a specific interrupt vector optionally with auto-EOI

This patchset implements the KVM part of the synthetic interrupt controller (SynIC) which is a building block of the Hyper-V paravirtualized device bus (vmbus). SynIC is a lapic extension, which is controlled via MSRs and maintains for each vCPU - 16 synthetic interrupt "lines" (SINT's); each can be configured to trigger a specific interrupt vector optionally with auto-EOI

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hello, since applying the patches related to XSA-36 Xen recognizes a broken IVRS ACPI table and disables I/O virtualisation. I contacted the manufacturer of the mainboard/BIOS and they want to help me by providing a patched BIOS - so far so good. However, they need details about what to fix, which I don''t know either. Could you pls. give me some hints which I can forward to the

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, I''ve not tried pv_ops for a long time but just got a new system (Supermicro X9DRL-iF) so decided to try 3.5.0 with the latest Xen 4.2-unstable, unfortunately the system crashes immediately after loading dom0: traps.c:486:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] I''ve tried loading both bzImage and vmlinuz (gzip compressed vmlinuz) with the same

Greetings, I got the below dmesg and the first bad commit is commit cf39c8e5352b4fb9efedfe7e9acb566a85ed847c Merge: 3398d25 23b7eaf Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Sep 4 17:45:39 2013 -0700 Merge tag ''stable/for-linus-3.12-rc0-tag'' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull Xen updates from Konrad

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-3 Severity: grave Justification: causes non-serious data loss -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash

Hello, I''m using Xen 4.0.0 compiled from source with the 2.6.31.13 kernel that it pulls down on its own. I added support for the aacraid driver to the kernel using ''make menuconfig'' from the build-linux-2.6-pvops_x86_64 subdirectory, and then built and installed the whole thing using ''make install'' from the xen-4.0.0 directory. I compiled this

Hey, Are there any known issues with the Intel''s integrated HD graphics 4000? I just bought a new laptop and have tried everything I can think of to get Xen to load. After choosing Xen in GRUB, it just boots to a black screen. There is no error message , no dmesg output, nothing. I have no idea what is causing this problem. I''ve gotten Xen to install with no problems on another

<<handle_msi_irq_storm.patch>> Hi, Keir, This patch handles MSI irq storm. Unluckily, I have observed this phenomenon again. This will happen when some kind of MSI-X capable NIC is assigned to an HVM guest. The basic idea is to mask the interrupt on receiving the second interrupt and set a timer to unmask after 1ms. Can you have a look and give some comments on that? Thanks! Best

I tried for a couple of times to add an information that might help you with regard to Bug #603713 by sending mailto "603713 at bugs.debian.org" But it never appeared there - so I try to let you know how to work around that bug this way. If you decide not to take this mail into account I won't bother you any more Regards Andreas -----Urspr?ngliche Nachricht----- Von: Balg, Andreas