similar to: XSA-36 / howto fix broken IVRS ACPI table

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

I have the same motherboard. The chipset has 2 IOAPICs: one in the NB (00:00.1), and another in the SB (00:14.0). As currently configured by the BIOS, the NB IOAPIC is _entirely_ disabled, with only the SB IOAPIC enabled and configured. From 48693.pdf, it would seem that the NB is improperly configured, as 6.4.1 recommends that "The IOAPIC should be enabled by the system BIOS and the

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> This patch handle additional cases for IVRS bugs where special->handle is not correctly initialized for IOAPIC and HPETS due to firmware bugs. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Provide logic in "is_ioapic_overidden()" Signed-off-by: Jan Beulich <JBeulich@suse.com> ---

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> This patch add an additional logic to check for the often case when the special->handle is not initialized due to firmware bugs. but the special->usedid is correct. If users overide this using the command line option ivrs_ioapic, then it should use the value instead. --- This patch is supposed to follow the patches:

Hey I wanted to try my hand at doing some GPU passthrough so on my ASUS M5A97 which in the pass worked with an older BIOS (but said BIOS had issues after S3 suspend) - but with a BIOS the PCI passthrough does not work. That is due to:: (XEN) IVHD Error: Invalid IO-APIC 0xff (XEN) AMD-Vi: Error initialization

Hi Konrad, Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361). It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0." With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between. dmesg and xm dmesg attached -- Sander Dom0 shows: total

For one we shouldn''t accept IVHD tables specifying IO-APIC IDs beyond the limit we support (MAX_IO_APICS, currently 128). And then we shouldn''t memset() a pointer allocation of which failed. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -674,6 +674,13 @@ static u16 __init

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

Today is my day! This is with Xen 4.4 (pulled today) when I build a kernel in dom0 and have two guests launching at the same time. This is what I get: (XEN) Assertion ''l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) == hashent->mfn'' failed at domain_page.c:203 and it blows up. Here is the full log: \ \/ /___ _ __ | || | | || | _ _ _ __ ___| |_ __ _| |__ | | ___

Hi Jan, After commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, booting dom0 stalls several times. Sometimes this results in RCU stall warnings from the dom0 kernel, hitting the "any" key, on normal or serial console, makes the boot continue for a while but it stalls several times. (It also stalls on shutdown BTW) I have

Hello, I'm facing issues with a Point of View GT210/218 and nouveau drivers. I'm using ubuntu server with LXDE on top of it... *lshw -c video* output: *-display description: VGA compatible controller product: GT218 [GeForce 210] vendor: NVIDIA Corporation physical id: 0 bus info: pci at 0000:01:00.0 version: a2 width: 64 bits clock:

Hello all..... I would like to know if anyone here has had good experience with this Supermicro motherboard.....http://supermicro.com/products/motherboard/P4/E7221/P8SCT.cfm I am thinking about using it in an entry level mail and file server with a 3ware card and 200 GB SATA drives. Cost is a factor here otherwise I would go for an Opteron board instead. JC

Hi all I already posted about this problem on xen-users some time ago (http://markmail.org/message/sbgtyjqh6bzmqx4s) but I couldn''t resolve my problem using help from people on xen-users, so I''m posting here . I have a problem with enabling IOMMU on Xen 4.2.1. When I enable it in BIOS and in grub.conf using iommu=1 kernel option, my machine cannot boot. I get a following error

I'm running CentOS 5.1 with all updates, and the xen kernel. For some reason the OS is not seeing the full amount of ram. #uname -a Linux CentOS-VM-A 2.6.18-53.1.21.el5xen #1 SMP Tue May 20 10:03:27 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux # free total used free shared buffers cached Mem: 6104064 3445136 2658928 0 1412236

Hello, Are XSA-289 and XSA-274/CVE-2018-14678 fixed with Xen recent 4.8, 4.10 and kernel 4.9.177 packages ? Thank you

Ian Jackson writes ("64bit PV guest breakout [XSA-213]"): > Source: xen > Version: 4.4.1-9 > Severity: important > Tags: security upstream fixed-upstream > > See > https://xenbits.xen.org/xsa/advisory-213.html Ian Jackson writes ("grant transfer allows PV guest to elevate privileges [XSA-214]"): > Source: xen > Version: 4.4.1-9 > Severity:

Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"): > On Thu, May 04, 2017 at 05:59:18PM +0100, Ian Jackson wrote: > > Should I put jessie-security in the debian/changelog and dgit push it > > (ie, from many people's pov, dput it) ? > > Yes, the distribution line should be jessie-security, but please send > a

Dear Security Team, I have prepared a new upload addressing a number of open security issues in Xen. Due to the complexity of the patches that address XSA-273 [0] the packages have been built from upstream's staging-4.8 / staging-4.10 branch again as recommended in that advisory. Commits on those branches are restricted to those that address the following XSAs (cf. [1]): - XSA-273

Moritz M?hlenhoff writes ("Re: Updated Xen packages for XSA 216..225"): > Since the queue was already quite big and this update was ready > I went ahead and released what we had for now. Yes, sorry, I should have been explicit that that's what I expected you to do... Ian.