similar to: [PATCH 1/1 V3] x86/AMD-Vi: Add additional check for invalid special->handle

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:

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

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

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

Another bundle of issues from Coverity triage. The first one is in x86/mm, and looks scarier than it is. The others are all in xen/drivers and AFAICT are pretty minor. Cheers, Tim.

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

This patch set adds basic supports for amd next generation iommu (IOMMUv2) hardware. IOMMUv2 supports various new features advertised by iommu extended feature register. It introduces guest level IO translation and supports state-of-the-art ATS/ATC devices with demand paging capability. Please refer to AMD IOMMU Architectural Specification [1] for more details. Thanks, Wei [1]

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

Hi, I''m running a machine with: - Hypervisor: xen-unstable - Dom0: xen/next-2.6.32.17 commit c3f5aba942c7516a5c76c47345ff0a473daf2542 Hardware: -MSI 890FXA-GD70 with AMD IOMMU -Phenom X6 I''m trying to do PCI passthrough to a HVM, this fails with: Error: Failed to assign device to IOMMU (0000:04:00.0@100,msitranslate=1,power_mgmt=0) Error: pci: to avoid potential security

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

Hello everyone, Reposting with after having applied the (minor) fixes suggested by Wei and Jan. Allen, if you can tell us what you think about this, or suggest someone else to ask some feedback to, if you''re no longer involved with VT-d, that would be great! :-) -- As already discussed here [1], dealing with IOMMU faults in interrupt context may cause nasty things to happen, up to

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

Hi, unfortunatly your latest change "AMD,IOMMU: Clean up old entries in remapping tables when creating new one" (Changeset 26517 in xen-unstable and 25975 in xen-4.2-testing) is causing a CPU0 Panic at boot for me. When i tried to boot latest versions of xen unstable or xen-testing, my dom0 gives me the message: (XEN) ************************************* (XEN) Panic on CPU 0: (XEN)

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 that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

-- Advanced Micro Devices GmbH Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 WEEE-Reg-Nr: DE 12919551 Geschäftsführer: Alberto Bozzo, Andrew Bowd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi. Package: xen-hypervisor-4.1-amd64 Starting guest VM, after package upgrade: xm create winxp Using config file "./winxp". Error: failed to assign device: maybe the platform doesn't support VT-d, or VT-d isn't enabled properly? If I set up VM properly after few months, but I remember, I met same error only after package upgrade. Pastebin logs, for check my errors: xm info

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

On 26/06/18 19:07, Michael S. Tsirkin wrote: > So as I pointed out new virtio 0 device isn't really welcome ;) Agreed, virtio-iommu is expected to be implemented on virtio 1 and later. I'll remove the two legacy-related paragraph from the spec and add a check in the driver as you suggested, to avoid giving the wrong idea. > No one bothered implementing virtio 1 in MMIO for all the