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 mentioned IRQ sharing in [1]? May I just live with the NorthBridge disabled IOAPIC? [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01016.html [1] http://lists.xen.org/archives/html/xen-devel/2013-04/msg02349.html
Eric Shelton
2013-May-04 00:09 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
> 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 mentioned IRQ > sharing in [1]? May I just live with the NorthBridge disabled IOAPIC? > > > [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01016.html > [1] http://lists.xen.org/archives/html/xen-devel/2013-04/msg02349.htmlDid you try the xen boot option mentioned in XSA-36? iommu=amd-iommu-perdev-intremap Add it to the line in grub.conf for the hypervisor (e.g., "kernel /boot/xen.gz dom0_mem=2048M iommu=1,no-amd-iommu-perdev-intremap") - Eric
Marcus Osdoba
2013-May-04 10:20 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
Am 04.05.2013 02:09, schrieb Eric Shelton:> Did you try the xen boot option mentioned in XSA-36? > > iommu=amd-iommu-perdev-intremap > > Add it to the line in grub.conf for the hypervisor (e.g., "kernel > /boot/xen.gz dom0_mem=2048M iommu=1,no-amd-iommu-perdev-intremap")Hello Eric, Thanks for the hint. Unfortuantly this wasn''t a solution as reported in [0]. Even with the option "no-amd-iommu-perdev-intremap" the I/O virtualisation remains disabled (xm dmesg output see below). Regards, Marcus [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01016.html (XEN) Xen version 4.1.4 (Debian 4.1.4-3) (waldi@debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) Fri Apr 19 13:32:48 UTC 2013 (XEN) Bootloader: GRUB 1.99-27+deb7u1 (XEN) Command line: placeholder com1=115200,8n1 console=com1 iommu=verbose,no-amd-iommu-perdev-intremap dom0_mem=768M (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) EDID info not retrieved because of reasons unknown (XEN) Disc information: (XEN) Found 3 MBR signatures (XEN) Found 3 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 0000000000098800 (usable) (XEN) 000000000009f800 - 00000000000a0000 (reserved) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfda0000 (usable) (XEN) 00000000cfda0000 - 00000000cfdd1000 (ACPI NVS) (XEN) 00000000cfdd1000 - 00000000cfe00000 (ACPI data) (XEN) 00000000cfe00000 - 00000000cff00000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000130000000 (usable) (XEN) ACPI: RSDP 000F6B80, 0014 (r0 GBT ) (XEN) ACPI: RSDT CFDD1000, 004C (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: FACP CFDD1080, 0074 (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: DSDT CFDD1100, 792A (r1 GBT GBTUACPI 1000 MSFT 3000000) (XEN) ACPI: FACS CFDA0000, 0040 (XEN) ACPI: SSDT CFDD8B00, 0544 (r1 PTLTD POWERNOW 1 LTP 1) (XEN) ACPI: MSDM CFDD9080, 0055 (r3 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: HPET CFDD9100, 0038 (r1 GBT GBTUACPI 42302E31 GBTU 98) (XEN) ACPI: MCFG CFDD9140, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: MATS CFDD91C0, 0034 (r1 GBT 0 0) (XEN) ACPI: TAMG CFDD9230, 0202 (r1 GBT GBT B0 5455312E BG^A^A 53450101) (XEN) ACPI: APIC CFDD8A40, 00BC (r1 GBT GBTUACPI 42302E31 GBTU 1010101) (XEN) ACPI: MATS CFDD9440, 61FD (r1 MATS RCM 80000001 INTL 20061109) (XEN) ACPI: IVRS CFDDF6B0, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) System RAM: 4093MB (4191456kB) (XEN) Domain heap initialised (XEN) Processor #0 0:6 APIC version 16 (XEN) Processor #1 0:6 APIC version 16 (XEN) IOAPIC[0]: apic_id 8, version 33, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Table is not found! (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2818.986 MHz processor. (XEN) Initing memory sharing. (XEN) IVHD Error: Conflicting IO-APIC 0x8 entries (XEN) AMD-Vi: Error initialization (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 2 CPUs (XEN) do_IRQ: 1.231 No irq handler for vector (irq -1) (XEN) Xenoprofile: AMD IBS detected (0x0000001f) (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32
Andrew Cooper
2013-May-04 15:25 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
On 03/05/2013 21:23, Marcus Osdoba wrote:> 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.XSA-36 is the "official" solution, and is correct from a security point of view. From what I understand, the root cause of the problem you have is due to bad ACPI tables from the BIOS.> > I''m not sure about my alternatives. How "dangerous" is the mentioned IRQ > sharing in [1]? May I just live with the NorthBridge disabled IOAPIC?If you are the admin of all the VMs, or trust the admin of all the VMs, then it is fine. The danger is that an untrusted admin can use the problems to launch a DoS against other VMs on the system. ~Andrew> > > [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01016.html > [1] http://lists.xen.org/archives/html/xen-devel/2013-04/msg02349.html > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Eric Shelton
2013-May-05 02:54 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
On Sat, May 4, 2013 at 6:20 AM, Marcus Osdoba <marcus.osdoba@googlemail.com> wrote:> Am 04.05.2013 02:09, schrieb Eric Shelton: > >> Did you try the xen boot option mentioned in XSA-36? >> >> iommu=amd-iommu-perdev-intremap >> >> Add it to the line in grub.conf for the hypervisor (e.g., "kernel >> /boot/xen.gz dom0_mem=2048M iommu=1,no-amd-iommu-perdev-intremap") > > Hello Eric, > > Thanks for the hint. Unfortuantly this wasn''t a solution as reported in [0]. > Even with the option "no-amd-iommu-perdev-intremap" the I/O virtualisation > remains disabled (xm dmesg output see below). > > Regards, > Marcus > > [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01016.html > > (XEN) Xen version 4.1.4 (Debian 4.1.4-3) (waldi@debian.org) (gcc version > 4.7.2 (Debian 4.7.2-5) ) Fri Apr 19 13:32:48 UTC 2013 > (XEN) Bootloader: GRUB 1.99-27+deb7u1 > (XEN) Command line: placeholder com1=115200,8n1 console=com1 > iommu=verbose,no-amd-iommu-perdev-intremap dom0_mem=768M. . .> (XEN) IOAPIC[0]: apic_id 8, version 33, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs. . .> (XEN) IVHD Error: Conflicting IO-APIC 0x8 entries > (XEN) AMD-Vi: Error initialization > (XEN) I/O virtualisation disabled. . . I have the same motherboard with I/O virtualization running. You are welcome to follow my path if you wish. I detailed the issues with the 970A-UD3 motherboard in response to [1], so it should give you a clear idea as to the defect and whether you consider what I am doing meets your goals. My view is that the particular misconfiguration with this board, in which the ACPI IVRS table lists an unused northbridge IOAPIC, is reasonably ignored as done in the below patch. My xen boot line is as follows: kernel /boot/xen.gz dom0_mem=2048M loglvl=all guest_loglvl=all apic_verbosity=debug e820-verbose=1 iommu=debug,verbose I have patched iommu_acpi.c as follows: --- orig/xen/drivers/passthrough/amd/iommu_acpi.c 2013-05-04 21:18:18.148000000 -0400 +++ xen-unstable-3f28d0077788e7f8cd3ee25b023a4225d7e26e87/xen/drivers/passthrough/amd/iommu_acpi.c 2013-04-23 22:27:28.028000000 -0400 @@ -679,8 +679,9 @@ special->handle); else { - printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n", + printk(XENLOG_ERR "ignored - IVHD Error: Conflicting IO-APIC %#x entries\n", special->handle); + break; if ( amd_iommu_perdev_intremap ) return 0; } @@ -702,12 +703,14 @@ } break; } + /* if ( apic == nr_ioapics ) { printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n", special->handle); return 0; } + */ break; case ACPI_IVHD_HPET: /* set device id of hpet */ xl dmesg reports the following: (XEN) Xen version 4.3-unstable (root@) (gcc (Gentoo 4.6.3 p1.11, pie-0.5.2) 4.6.3) debug=y Tue Apr 23 22:28:54 EDT 2013 (XEN) Latest ChangeSet: unavailable (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=2048M loglvl=all guest_loglvl=all apic_verbosity=debug e820-verbose=1 iommu=debug,verbose . . . (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 8, version 33, address 0xfec00000, GSI 0-23 . . . (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x8 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x8 (XEN) ignored - IVHD Error: Conflicting IO-APIC 0x8 entries (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling per-device vector maps (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled . . . Best of luck to you... - Eric
Hans Mueller
2013-May-05 12:15 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
On Saturday, 4. May 2013 12:20:14 Marcus Osdoba wrote:> Am 04.05.2013 02:09, schrieb Eric Shelton: > > Did you try the xen boot option mentioned in XSA-36? > > > > iommu=amd-iommu-perdev-intremap > > > > Add it to the line in grub.conf for the hypervisor (e.g., "kernel > > /boot/xen.gz dom0_mem=2048M iommu=1,no-amd-iommu-perdev-intremap") > > Hello Eric, > > Thanks for the hint. Unfortuantly this wasn''t a solution as reported in > [0]. Even with the option "no-amd-iommu-perdev-intremap" the I/O > virtualisation remains disabled (xm dmesg output see below).XSA-36 says that for Xen 4.1.x ''iommu=amd-iommu-global-intremap'' is the related parameter instead of ''iommu=amd-iommu-perdev-intremap''. In addition my remark that it would not really help was refered to problems regarding interrupt sharing which persisted and seem to be independent of XSA-36 and the disabled I/O virtualisation. For me ''iommu=amd-iommu-perdev-intremap'' (Xen 4.2.x) worked and enabled the I/O virtualisation with ''global vector map'': (XEN) Xen version 4.2.2-pre (@sec.chaos) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Sun Mar 3 16:35:02 CET 2013 (XEN) Latest ChangeSet: Wed Feb 13 17:00:15 2013 +0000 26013:e28ffa5410df ... (XEN) Command line: ucode=-1 dom0_mem=1024M,max:1024M com1=115200,8n1,0x3f8,4 console=com1 cpufreq=xen:ondemand loglvl=all guest_loglvl=all apic_verbosity=debug e820-verbose=1 iommu=debug,verbose,no-amd-iommu-perdev- intremap ... (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0x0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x8 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0x0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0x0 flags 0x0 (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x8 (XEN) IVHD Error: Conflicting IO-APIC 0x8 entries (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)! (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed However, since upgrading the BIOS to version F8c this is no longer required, the conflicting IO-APIC entry is removed and ''per-device vector maps'' are enabled w/o passing any IOMMU related parameter to Xen: (XEN) Xen version 4.2.2 (@sec.chaos) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Sun Apr 28 03:45:10 CEST 2013 (XEN) Latest ChangeSet: Tue Apr 23 18:42:55 2013 +0200 26064:754008dbaa6c ... (XEN) Command line: com1=115200,8n1,0x3f8,4 console=com1 ucode=-1 cpufreq=xen:ondemand dom0_mem=1024M,max:1024M conring_size=64k loglvl=all guest_loglvl=all cpuinfo=on e820-verbose=on iommu=debug apic_verbosity=debug ... (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0x0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x8 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0x0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0x0 (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling per-device vector maps (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled Of course the northbridge IO-APIC is disabled but it wasn''t properly setup and didn''t work before, either. Regards Hans
Hans Mueller
2013-May-05 12:43 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
On Saturday, 4. May 2013 22:54:57 Eric Shelton wrote:> I have the same motherboard with I/O virtualization running. You are > welcome to follow my path if you wish. I detailed the issues with the > 970A-UD3 motherboard in response to [1], so it should give you a clear > idea as to the defect and whether you consider what I am doing meets > your goals. My view is that the particular misconfiguration with this > board, in which the ACPI IVRS table lists an unused northbridge > IOAPIC, is reasonably ignored as done in the below patch. > > My xen boot line is as follows: > kernel /boot/xen.gz dom0_mem=2048M loglvl=all guest_loglvl=all > apic_verbosity=debug e820-verbose=1 iommu=debug,verbose > > I have patched iommu_acpi.c as follows: > --- orig/xen/drivers/passthrough/amd/iommu_acpi.c 2013-05-04 > 21:18:18.148000000 -0400 > +++ > xen-unstable-3f28d0077788e7f8cd3ee25b023a4225d7e26e87/xen/drivers/passthrou > gh/amd/iommu_acpi.c 2013-04-23 22:27:28.028000000 -0400 > @@ -679,8 +679,9 @@ > special->handle); > else > { > - printk(XENLOG_ERR "IVHD Error: Conflicting > IO-APIC %#x entries\n", > + printk(XENLOG_ERR "ignored - IVHD Error: > Conflicting IO-APIC %#x entries\n", > special->handle); > + break; > if ( amd_iommu_perdev_intremap ) > return 0; > } > @@ -702,12 +703,14 @@ > } > break; > } > + /* > if ( apic == nr_ioapics ) > { > printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n", > special->handle); > return 0; > } > + */ > break; > case ACPI_IVHD_HPET: > /* set device id of hpet */ > > xl dmesg reports the following: > (XEN) Xen version 4.3-unstable (root@) (gcc (Gentoo 4.6.3 p1.11, > pie-0.5.2) 4.6.3) debug=y Tue Apr 23 22:28:54 EDT 2013 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=2048M loglvl=all guest_loglvl=all > apic_verbosity=debug e820-verbose=1 iommu=debug,verbose > . . . > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 8, version 33, address 0xfec00000, GSI 0-23 > . . . > (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 > (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x8 > (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 > (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0 > (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 > (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x8 > (XEN) ignored - IVHD Error: Conflicting IO-APIC 0x8 entries > (XEN) AMD-Vi: IOMMU 0 Enabled. > (XEN) AMD-Vi: Enabling per-device vector maps > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Interrupt remapping enabledPerhaps I missed something but as your approach ignores the improper entry for the northbridge it should behave similar to using the patched BIOS (F8c) which removes this entry from the IVRS table? At all I use the patched BIOS w/o any patches for Xen and w/o the ''iommu=amd-iommu-perdev-intremap'' parameter and I/O virtualisation becomes enabled (Xen version 4.2.x ChangeSet 26064:754008dbaa6c): (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling per-device vector maps (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled Regards Hans
Eric Shelton
2013-May-06 00:38 UTC
Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
On Sun, May 5, 2013 at 8:43 AM, Hans Mueller <mcbeagle@gmx.de> wrote:> On Saturday, 4. May 2013 22:54:57 Eric Shelton wrote: >> I have the same motherboard with I/O virtualization running. You are >> welcome to follow my path if you wish. I detailed the issues with the >> 970A-UD3 motherboard in response to [1], so it should give you a clear >> idea as to the defect and whether you consider what I am doing meets >> your goals. My view is that the particular misconfiguration with this >> board, in which the ACPI IVRS table lists an unused northbridge >> IOAPIC, is reasonably ignored as done in the below patch. >> >> My xen boot line is as follows: >> kernel /boot/xen.gz dom0_mem=2048M loglvl=all guest_loglvl=all >> apic_verbosity=debug e820-verbose=1 iommu=debug,verbose >> >> I have patched iommu_acpi.c as follows: >> --- orig/xen/drivers/passthrough/amd/iommu_acpi.c 2013-05-04 >> 21:18:18.148000000 -0400 >> +++ >> xen-unstable-3f28d0077788e7f8cd3ee25b023a4225d7e26e87/xen/drivers/passthrou >> gh/amd/iommu_acpi.c 2013-04-23 22:27:28.028000000 -0400 >> @@ -679,8 +679,9 @@ >> special->handle); >> else >> { >> - printk(XENLOG_ERR "IVHD Error: Conflicting >> IO-APIC %#x entries\n", >> + printk(XENLOG_ERR "ignored - IVHD Error: >> Conflicting IO-APIC %#x entries\n", >> special->handle); >> + break; >> if ( amd_iommu_perdev_intremap ) >> return 0; >> } >> @@ -702,12 +703,14 @@ >> } >> break; >> } >> + /* >> if ( apic == nr_ioapics ) >> { >> printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n", >> special->handle); >> return 0; >> } >> + */ >> break; >> case ACPI_IVHD_HPET: >> /* set device id of hpet */ >> >> xl dmesg reports the following: >> (XEN) Xen version 4.3-unstable (root@) (gcc (Gentoo 4.6.3 p1.11, >> pie-0.5.2) 4.6.3) debug=y Tue Apr 23 22:28:54 EDT 2013 >> (XEN) Latest ChangeSet: unavailable >> (XEN) Bootloader: GNU GRUB 0.97 >> (XEN) Command line: dom0_mem=2048M loglvl=all guest_loglvl=all >> apic_verbosity=debug e820-verbose=1 iommu=debug,verbose >> . . . >> (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) >> (XEN) IOAPIC[0]: apic_id 8, version 33, address 0xfec00000, GSI 0-23 >> . . . >> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 >> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x8 >> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 >> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0 >> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 >> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x8 >> (XEN) ignored - IVHD Error: Conflicting IO-APIC 0x8 entries >> (XEN) AMD-Vi: IOMMU 0 Enabled. >> (XEN) AMD-Vi: Enabling per-device vector maps >> (XEN) I/O virtualisation enabled >> (XEN) - Dom0 mode: Relaxed >> (XEN) Interrupt remapping enabled > > Perhaps I missed something but as your approach ignores the improper entry for > the northbridge it should behave similar to using the patched BIOS (F8c) which > removes this entry from the IVRS table? > > At all I use the patched BIOS w/o any patches for Xen and w/o the > ''iommu=amd-iommu-perdev-intremap'' parameter and I/O virtualisation becomes > enabled (Xen version 4.2.x ChangeSet 26064:754008dbaa6c): > > (XEN) AMD-Vi: IOMMU 0 Enabled. > (XEN) AMD-Vi: Enabling per-device vector maps > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Interrupt remapping enabled > > Regards > HansI suspect the obtained result is the same, or at least very similar. I put the patch (more of a crude hack) together a while back to enable interrupt sharing, before Gigabyte made a ver F8c for you to try out. Also, as far as I can tell Gigabyte has not made F8c publicly generally - the latest BIOS I see on their website is F8a from December 2012. Enabling and correctly configuring the northbridge is pretty easy from a register programming perspective. The more difficult part is getting the corresponding ACPI table changes fed to Xen as well, as Xen looks to them for configuration. I know how to go about it at this point, but another project has priority over it for the next week or two. - Eric