* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
@ 2013-05-04 0:09 Eric Shelton
2013-05-04 10:20 ` Marcus Osdoba
0 siblings, 1 reply; 8+ messages in thread
From: Eric Shelton @ 2013-05-04 0:09 UTC (permalink / raw)
To: Marcus Osdoba, xen-devel@lists.xen.org
> 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
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")
- Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
2013-05-04 0:09 IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3 Eric Shelton
@ 2013-05-04 10:20 ` Marcus Osdoba
2013-05-05 2:54 ` Eric Shelton
2013-05-05 12:15 ` Hans Mueller
0 siblings, 2 replies; 8+ messages in thread
From: Marcus Osdoba @ 2013-05-04 10:20 UTC (permalink / raw)
To: Eric Shelton; +Cc: xen-devel@lists.xen.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
2013-05-04 10:20 ` Marcus Osdoba
@ 2013-05-05 2:54 ` Eric Shelton
2013-05-05 12:43 ` Hans Mueller
2013-05-05 12:15 ` Hans Mueller
1 sibling, 1 reply; 8+ messages in thread
From: Eric Shelton @ 2013-05-05 2:54 UTC (permalink / raw)
To: Marcus Osdoba; +Cc: xen-devel@lists.xen.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
2013-05-05 2:54 ` Eric Shelton
@ 2013-05-05 12:43 ` Hans Mueller
2013-05-06 0:38 ` Eric Shelton
0 siblings, 1 reply; 8+ messages in thread
From: Hans Mueller @ 2013-05-05 12:43 UTC (permalink / raw)
To: xen-devel, Eric Shelton
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
Hans
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
2013-05-05 12:43 ` Hans Mueller
@ 2013-05-06 0:38 ` Eric Shelton
0 siblings, 0 replies; 8+ messages in thread
From: Eric Shelton @ 2013-05-06 0:38 UTC (permalink / raw)
To: Hans Mueller; +Cc: xen-devel@lists.xen.org
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
> Hans
I 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
2013-05-04 10:20 ` Marcus Osdoba
2013-05-05 2:54 ` Eric Shelton
@ 2013-05-05 12:15 ` Hans Mueller
1 sibling, 0 replies; 8+ messages in thread
From: Hans Mueller @ 2013-05-05 12:15 UTC (permalink / raw)
To: xen-devel, Marcus Osdoba
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
@ 2013-05-03 20:23 Marcus Osdoba
2013-05-04 15:25 ` Andrew Cooper
0 siblings, 1 reply; 8+ messages in thread
From: Marcus Osdoba @ 2013-05-03 20:23 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-05-06 0:38 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-04 0:09 IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3 Eric Shelton
2013-05-04 10:20 ` Marcus Osdoba
2013-05-05 2:54 ` Eric Shelton
2013-05-05 12:43 ` Hans Mueller
2013-05-06 0:38 ` Eric Shelton
2013-05-05 12:15 ` Hans Mueller
-- strict thread matches above, loose matches on Subject: below --
2013-05-03 20:23 Marcus Osdoba
2013-05-04 15:25 ` Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.