similar to: [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message

... instead of open coding it. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct return; } - memset(&msg, 0, sizeof(msg)); - msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff; - msg.data |= 1 << 14; -

x86:x2apic: Disable x2apic on x86-32 permanently x2apic initialization on x86_32 uses vcpu pointer before it is initialized. As x2apic is unlikely to be used on x86_32, this patch disables x2apic permanently on x86_32. It also asserts the sanity of vcpu pointer before dereference to prevent further misuse. Signed-off-by: Fengzhe Zhang <fengzhe.zhang@intel.com> diff -r 02c0af2bf280

With the .end() accessor having become optional and noting that several of the accessors'' behavior really depends on the result of msi_maskable_irq(), the splits the MSI IRQ chip type into two - one for the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich

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

Hi, on a Nehalem system with VT-d enabled we are seeing strange ACPI-Table contents, especially a corrupted DMAR entry. The hypervisor shows following data on boot: (XEN) ACPI: RSDP 000F80E0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT BF7C469E, 00D4 (r1 PTLTD XSDT 60000 LTP 0) (XEN) ACPI: FACP BF7C9CC9, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240) (XEN) ACPI: DSDT BF7C4772, 54D3 (r1

On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang <wangyijing at huawei.com> wrote: > On 2014/7/4 10:43, Ilia Mirkin wrote: >> On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing at huawei.com> wrote: >>> Hi Brian, >>> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this >>> card has no

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

So I want to turn iommu support on in a guest ( <type arch='x86_64' machine='pc-q35-4.1'>hvm</type>). Per [1] I tried to add to devices either <devices> <iommu model='intel'> <driver intremap='on'/> </iommu> </devices> or just a simpler <devices> <iommu model='intel /'> </devices>

Wei, Quick question: Am I reading the code correctly, that even with per-device interrupt remap tables, that GSIs are accounted to the intremap table of the corresponding IOAPIC, presumably because the IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In that case, then we need all devices sharing the same IOAPIC must not have any vector collisions. Is that correct? -George

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

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 All, I''m getting the attached panic in the hypervisor on a Sun 6270 running xen-testing.hg changeset 19913:6063c16aeeaa. I can run xen-3.3.1 from the standard SLES 11 distribution (which says that it''s changeset 18546 but it has many patches). Any ideas? thanks, dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Implement MSI support in APIC. Note that MSI and MMIO APIC registers are at the same memory location, but actually not on the global bus: MSI is on PCI bus, APIC is connected directly to the CPU. We map them on the global bus at the same address which happens to work because MSI registers are reserved in APIC MMIO and vice versa. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

Implement MSI support in APIC. Note that MSI and MMIO APIC registers are at the same memory location, but actually not on the global bus: MSI is on PCI bus, APIC is connected directly to the CPU. We map them on the global bus at the same address which happens to work because MSI registers are reserved in APIC MMIO and vice versa. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

xen/arch/x86/crash.c | 116 ++++++++++++++++++++++++++++++++++----- xen/arch/x86/machine_kexec.c | 19 ++++++ xen/arch/x86/x86_64/entry.S | 34 +++++++++++ xen/include/asm-x86/desc.h | 45 +++++++++++++++ xen/include/asm-x86/processor.h | 4 + 5 files changed, 203 insertions(+), 15 deletions(-) Experimentally, certain crash kernels will triple fault very early

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-0153 / XSA-36 version 3 interrupt remap entries shared and old ones not cleared on AMD IOMMUs UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= To avoid an erratum in early hardware, the Xen AMD IOMMU code by default chooses to use a single interrupt

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

Dear All I am using Centos 7 with Xen 4.6 on a Dell Poweredge T430 When the machine boots, after the 'Scrubbing Free RAM' message, I get a screen filled with little white squares until the login prompt, so I cannot see what is happening as the machine boots. Also there is nothing on the screen when I reboot. My /etc/default/grub is GRUB_DISTRIBUTOR="$(sed 's, release

On Tue, Feb 11, 2020 at 09:09:36AM -0500, Mauricio Tavares wrote: > So I want to turn iommu support on in a guest ( <type arch='x86_64' > machine='pc-q35-4.1'>hvm</type>). Per [1] I tried to add to devices > either > > <devices> > <iommu model='intel'> > <driver intremap='on'/> > </iommu> >