similar to: Cannot turn iommu on inside guest

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

Hi, I have a guest enabled vIOMMU, but on the guest there are several devices in the same iommu group. Could someone help to check if I missed something? Thank you very much! 1. guest xml: # virsh edit q ... <os> <type arch='x86_64' machine='pc-q35-rhel7.5.0'>hvm</type> <loader readonly='yes' secure='yes'

During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn''t passed back correctly. While this is benign in most cases (as the value isn''t being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan

All, here is my domain xml <domain type='kvm'> <name>tests</name> <uuid>76bc677f-ee5b-ef0b-1d02-72d12785b1d8</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc-0.12'>hvm</type> <boot

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

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

On Fri, Oct 30, 2020 at 07:44:43PM +0800, Jason Wang wrote: > >On 2020/10/30 ??6:54, Stefano Garzarella wrote: >>On Fri, Oct 30, 2020 at 06:02:18PM +0800, Jason Wang wrote: >>> >>>On 2020/10/30 ??1:43, Stefano Garzarella wrote: >>>>This patch enables the IOTLB API support for vhost-vsock devices, >>>>allowing the userspace to emulate an IOMMU

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

Dear George, Thanks for the input and ideas. Unfortunately bootscrub=false dos not work, not does setting nothing for vga, still get the 'Little white squares'! I am asking the xen-users as you suggest Regards, Francis From: "George Dunlap" <dunlapg at umich.edu> To: "Francis Greaves" <francis at choughs.net>, "centos-virt" <centos-virt

Yes I usually work headless, but I have been setting it up from new, so need to see what is going on. Regards Francis From: "Scot P. Floess" <sfloess at nc.rr.com> To: "Francis Greaves" <francis at choughs.net> Cc: "centos-virt" <centos-virt at centos.org> Sent: Monday, 22 February, 2016 17:02:12 Subject: Re: [CentOS-virt] Garbled screen

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

If this has already been done, please forgive me. However, if not, I''d like to submit this as a mechanism for generating a bootable grub2 stanza for hypervisors. As the /etc/grub.d/* files rely on defaults in /etc/default/grub, I added the following Xen specific variable: GRUB_CMDLINE_XEN_DEFAULT="console=com1 115200,8n1 dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin=true

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

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

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

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

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

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

Further to my messages back in May I have at last got round to trying to get my DomU to recognise USB devices. I am using Xen 4.6 with CentOS kernel 3.18.34-20.el7.x86_64. I have to manually make the port available before creating the DomU by issuing the command: xl pci-assignable-add 00:1a.0 otherwise nothing shows in: xl pci-assignable-list I have added this to my .cfg file as per the