* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
@ 2014-08-07 14:46 ` bugzilla-daemon
2014-08-07 14:47 ` bugzilla-daemon
` (21 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 14:46 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #1 from Marti Raudsepp <marti@juffo.org> ---
Created attachment 145421
--> https://bugzilla.kernel.org/attachment.cgi?id=145421&action=edit
crash_netconsole.txt
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
2014-08-07 14:46 ` [Bug 81841] " bugzilla-daemon
@ 2014-08-07 14:47 ` bugzilla-daemon
2014-08-07 14:47 ` bugzilla-daemon
` (20 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 14:47 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #2 from Marti Raudsepp <marti@juffo.org> ---
Created attachment 145431
--> https://bugzilla.kernel.org/attachment.cgi?id=145431&action=edit
startup_dmesg.txt
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
2014-08-07 14:46 ` [Bug 81841] " bugzilla-daemon
2014-08-07 14:47 ` bugzilla-daemon
@ 2014-08-07 14:47 ` bugzilla-daemon
2014-08-07 15:30 ` bugzilla-daemon
` (19 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 14:47 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #3 from Marti Raudsepp <marti@juffo.org> ---
Created attachment 145441
--> https://bugzilla.kernel.org/attachment.cgi?id=145441&action=edit
dmidecode.txt
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (2 preceding siblings ...)
2014-08-07 14:47 ` bugzilla-daemon
@ 2014-08-07 15:30 ` bugzilla-daemon
2014-08-07 16:25 ` bugzilla-daemon
` (18 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 15:30 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
Marti Raudsepp <marti@juffo.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Kernel Version|3.13 (Ubuntu: |3.16.0 (originally Ubuntu
|3.13.0-32-generic) |3.13.0-32-generic)
--- Comment #4 from Marti Raudsepp <marti@juffo.org> ---
Also occurs with freshly built mainline kernel version 3.16.0.
[ 87.327457] ------------[ cut here ]------------
[ 87.327488] kernel BUG at drivers/iommu/amd_iommu.c:2382!
[ 87.327505] invalid opcode: 0000 [#1] SMP
[ 87.327526] Modules linked in: pci_stub(E) ipt_MASQUERADE(E) iptable_nat(E)
nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) xt_conntrack(E)
nf_conntrack(E) ipt_REJECT(E) xt_CHECKSUM(E) iptable_mangle(E) xt_tcpudp(E)
bridge(E) stp(E) llc(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E)
ip_tables(E) ebtable_nat(E) ebtables(E) x_tables(E) nct6775(E) hwmon_vid(E)
radeon(E) kvm_amd(E) kvm(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
snd_hda_codec_hdmi(E) snd_hda_intel(E) snd_hda_controller(E) snd_hda_codec(E)
i2c_algo_bit(E) crct10dif_pclmul(E) drm_kms_helper(E) crc32_pclmul(E)
ghash_clmulni_intel(E) snd_hwdep(E) aesni_intel(E) snd_pcm(E) ttm(E)
aes_x86_64(E) glue_helper(E) netconsole(E) drm(E) lrw(E) snd_timer(E)
configfs(E) snd(E) gf128mul(E) ablk_helper(E) cryptd(E) soundcore(E) lp(E)
serio_raw(E) k10temp(E) i2c_piix4(E) mac_hid(E) video(E) parport(E)
usb_storage(E) pata_acpi(E) hid_generic(E) usbhid(E) hid(E) alx(E) psmouse(E)
mdio(E) pata_atiixp(E) ahci(E) libahci(E)
[ 87.327963] CPU: 0 PID: 1452 Comm: qemu-system-x86 Tainted: G E
3.16.0 #1
[ 87.327986] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./FM2A88X Extreme6+, BIOS L3.16 04/16/2014
[ 87.328016] task: ffff880427a18000 ti: ffff880421280000 task.ti:
ffff880421280000
[ 87.328039] RIP: 0010:[<ffffffff816059dd>] [<ffffffff816059dd>]
__detach_device+0xad/0xb0
[ 87.328071] RSP: 0018:ffff880421283b38 EFLAGS: 00010046
[ 87.328088] RAX: 0000000000000000 RBX: ffff8804286e5240 RCX:
ffff880421283ae0
[ 87.328110] RDX: dead000000100100 RSI: 0000000000000086 RDI:
ffff8804286e5240
[ 87.328132] RBP: ffff880421283b58 R08: 0000000000000046 R09:
ffff8804299b8900
[ 87.328154] R10: ffff880000000000 R11: 000ffffffffff000 R12:
0000000000000000
[ 87.328175] R13: ffff88042127a610 R14: ffff88042744c040 R15:
ffff8804286e5240
[ 87.328197] FS: 00007f1d03857700(0000) GS:ffff88043ec00000(0000)
knlGS:0000000000000000
[ 87.328221] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 87.328239] CR2: 00007f1d03dc63a0 CR3: 0000000001c13000 CR4:
00000000000407f0
[ 87.328260] Stack:
[ 87.328268] dead000000100100 ffff88042127a600 ffff88042127a610
ffff88042744c040
[ 87.328299] ffff880421283b98 ffffffff81605a7e 0000000000000202
ffff88042744c040
[ 87.328333] ffff88042744c040 ffff880420a3c008 ffff8804242b0a80
ffff88007786dfd8
[ 87.328365] Call Trace:
[ 87.328378] [<ffffffff81605a7e>] amd_iommu_domain_destroy+0x9e/0x160
[ 87.328400] [<ffffffff816022db>] iommu_domain_free+0x1b/0x30
[ 87.328432] [<ffffffffa03628a3>] kvm_iommu_unmap_guest+0x53/0x60 [kvm]
[ 87.328461] [<ffffffffa0373059>] kvm_arch_destroy_vm+0x39/0x1f0 [kvm]
[ 87.328484] [<ffffffff810cfebd>] ? synchronize_srcu+0x1d/0x20
[ 87.328509] [<ffffffffa035b26e>] kvm_put_kvm+0x10e/0x220 [kvm]
[ 87.328535] [<ffffffffa035b3b8>] kvm_vcpu_release+0x18/0x20 [kvm]
[ 87.328556] [<ffffffff811d0a04>] __fput+0xe4/0x220
[ 87.328573] [<ffffffff811d0b8e>] ____fput+0xe/0x10
[ 87.328591] [<ffffffff8108cd74>] task_work_run+0xc4/0xe0
[ 87.328609] [<ffffffff8106ef18>] do_exit+0x2b8/0xa60
[ 87.328627] [<ffffffff8106f73f>] do_group_exit+0x3f/0xa0
[ 87.328645] [<ffffffff8107f100>] get_signal_to_deliver+0x1d0/0x6f0
[ 87.328668] [<ffffffff81012548>] do_signal+0x48/0x9d0
[ 87.328687] [<ffffffff8111d1bc>] ? acct_account_cputime+0x1c/0x20
[ 87.328708] [<ffffffff810a372b>] ? account_user_time+0x8b/0xa0
[ 87.329791] [<ffffffff810a3cf4>] ? vtime_account_user+0x54/0x60
[ 87.330869] [<ffffffff81012f39>] do_notify_resume+0x69/0xb0
[ 87.331950] [<ffffffff8172b32a>] int_signal+0x12/0x17
[ 87.333016] Code: fe ff ff eb b8 66 0f 1f 84 00 00 00 00 00 48 8b 35 69 b0
9a 00 49 39 f4 74 c1 48 89 df e8 8c fd ff ff 5b 41 5c 41 5d 41 5e 5d c3 <0f> 0b
90 66 66 66 66 90 55 48 89 e5 41 57 41 56 49 89 fe 41 55
[ 87.335373] RIP [<ffffffff816059dd>] __detach_device+0xad/0xb0
[ 87.336475] RSP <ffff880421283b38>
[ 87.337562] ---[ end trace bee5733468f37c81 ]---
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (3 preceding siblings ...)
2014-08-07 15:30 ` bugzilla-daemon
@ 2014-08-07 16:25 ` bugzilla-daemon
2014-08-07 17:56 ` bugzilla-daemon
` (17 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 16:25 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
Alex Williamson <alex.williamson@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alex.williamson@redhat.com
--- Comment #5 from Alex Williamson <alex.williamson@redhat.com> ---
What if you use vfio-pci instead of pci-assign? The BUG happens when the
kernel tries to detach a device from the domain, but the device doesn't
actually belong to a domain. VFIO likely already avoids this because the
bridge and device will both be in the same IOMMU group and therefore attached
to the same domain.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (4 preceding siblings ...)
2014-08-07 16:25 ` bugzilla-daemon
@ 2014-08-07 17:56 ` bugzilla-daemon
2014-08-07 18:11 ` bugzilla-daemon
` (16 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 17:56 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #6 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Alex Williamson from comment #5)
> What if you use vfio-pci instead of pci-assign?
I run into the dreaded error:
vfio: error, group 9 is not viable, please ensure all devices within the
iommu_group are bound to their vfio bus driver
There are some proposed workarounds on the web, like passing
vfio_iommu_type1.allow_unsafe_interrupts=1 or pci=realloc, but these seem to
change nothing for me.
So I tried adding all the PCI devices in the IOMMU group as passthrough devices
(including IDE, SMBus, audio and OHCI controllers). But then QEMU's SeaBIOS
gets so confused it can no longer find a hard drive to boot off.
But you're right. At least I can stop the non-functional virtual machine now,
so I've got that going for me, which is nice.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (5 preceding siblings ...)
2014-08-07 17:56 ` bugzilla-daemon
@ 2014-08-07 18:11 ` bugzilla-daemon
2014-08-07 18:53 ` bugzilla-daemon
` (15 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 18:11 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #7 from Alex Williamson <alex.williamson@redhat.com> ---
(In reply to Marti Raudsepp from comment #6)
> (In reply to Alex Williamson from comment #5)
> > What if you use vfio-pci instead of pci-assign?
>
> I run into the dreaded error:
> vfio: error, group 9 is not viable, please ensure all devices within the
> iommu_group are bound to their vfio bus driver
>
> There are some proposed workarounds on the web, like passing
> vfio_iommu_type1.allow_unsafe_interrupts=1 or pci=realloc, but these seem to
> change nothing for me.
None of these remotely address the issue. If you're running at least 3.12
there are quirks for the following AMD southbridge components:
* 1002:4385 SBx00 SMBus Controller
* 1002:439c SB7x0/SB8x0/SB9x0 IDE Controller
* 1002:4383 SBx00 Azalia (Intel HDA)
* 1002:439d SB7x0/SB8x0/SB9x0 LPC host controller
* 1002:4384 SBx00 PCI to PCI Bridge
* 1002:4399 SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
If your bridge does not match these, then AMD will need to confirm whether
isolation is provided between your devices. There is an ACS override patch
floating around which allows assuming device isolation, but this is generally a
bad idea, can introduce obscure bugs, and will not be merged upstream.
> So I tried adding all the PCI devices in the IOMMU group as passthrough
> devices (including IDE, SMBus, audio and OHCI controllers). But then QEMU's
> SeaBIOS gets so confused it can no longer find a hard drive to boot off.
Note that it's not required to assign all the devices, they simply need to be
detached from host drivers (ie. bound to pci-stub or vfio-pci).
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (6 preceding siblings ...)
2014-08-07 18:11 ` bugzilla-daemon
@ 2014-08-07 18:53 ` bugzilla-daemon
2014-08-07 19:47 ` bugzilla-daemon
` (14 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 18:53 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #8 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Alex Williamson from comment #7)
> > There are some proposed workarounds on the web
> None of these remotely address the issue.
I see. This page claims so: http://www.ovirt.org/Features/hostdev_passthrough
> there are quirks for the following AMD southbridge components
Nope, mine are 1022:780b, 1022:780c, 1022:780d, 1022:780e, 1022:780f, 1022:7809
> If your bridge does not match these, then AMD will need to confirm whether
> isolation is provided between your devices.
How would I go about confirming that? What are the chances that they care, and
provide accurate information to a random person?
> There is an ACS override patch
I already ran across it... https://bugzilla.redhat.com/show_bug.cgi?id=1113399
Would I be any worse off using this, compared to the old kvm pci-assign method?
> Note that it's not required to assign all the devices, they simply need to
> be detached from host drivers (ie. bound to pci-stub or vfio-pci).
Thanks, I will give it a shot tomorrow.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (7 preceding siblings ...)
2014-08-07 18:53 ` bugzilla-daemon
@ 2014-08-07 19:47 ` bugzilla-daemon
2014-08-08 2:48 ` bugzilla-daemon
` (13 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-07 19:47 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #9 from Alex Williamson <alex.williamson@redhat.com> ---
(In reply to Marti Raudsepp from comment #8)
> (In reply to Alex Williamson from comment #7)
> > > There are some proposed workarounds on the web
> > None of these remotely address the issue.
>
> I see. This page claims so: http://www.ovirt.org/Features/hostdev_passthrough
Sorry, it's wrong.
> > there are quirks for the following AMD southbridge components
>
> Nope, mine are 1022:780b, 1022:780c, 1022:780d, 1022:780e, 1022:780f,
> 1022:7809
>
> > If your bridge does not match these, then AMD will need to confirm whether
> > isolation is provided between your devices.
>
> How would I go about confirming that? What are the chances that they care,
> and provide accurate information to a random person?
AMD would need to confirm it. IOMMU groups are based on hardware advertised
isolation via the PCIe ACS capability. Without this, or a device specific
quirk to take its place, IOMMU groups must assume that peer-to-peer between
functions of a multi-function device is possible and therefore that the devices
are not isolated. Chances are that this new chipset in your system is taking
the exact same ASICs that were deemed not to do peer-to-peer on previous
chipsets, but we need that confirmation from AMD. Alex Deucher (see
MAINTAINERS) may have contacts available that can make that statement.
> > There is an ACS override patch
>
> I already ran across it...
> https://bugzilla.redhat.com/show_bug.cgi?id=1113399
> Would I be any worse off using this, compared to the old kvm pci-assign
> method?
I think the path forward is to get confirmation from AMD that these function
are isolated from each other and add quirks to the kernel. Then you won't have
the device dependencies in vfio-pci. The override patch allows you to do that
with just a kernel boot parameter. There's no gurantee that pci-assign will
ever be fixed since it's being phased out.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (8 preceding siblings ...)
2014-08-07 19:47 ` bugzilla-daemon
@ 2014-08-08 2:48 ` bugzilla-daemon
2014-08-08 10:19 ` bugzilla-daemon
` (12 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-08 2:48 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
Joel Schopp <joel.schopp@amd.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joel.schopp@amd.com
--- Comment #10 from Joel Schopp <joel.schopp@amd.com> ---
(In reply to Alex Williamson from comment #9)
> (In reply to Marti Raudsepp from comment #8)
> > (In reply to Alex Williamson from comment #7)
> > > > There are some proposed workarounds on the web
> > > None of these remotely address the issue.
> >
> > I see. This page claims so: http://www.ovirt.org/Features/hostdev_passthrough
>
> Sorry, it's wrong.
>
> > > there are quirks for the following AMD southbridge components
> >
> > Nope, mine are 1022:780b, 1022:780c, 1022:780d, 1022:780e, 1022:780f,
> > 1022:7809
> >
> > > If your bridge does not match these, then AMD will need to confirm whether
> > > isolation is provided between your devices.
> >
> > How would I go about confirming that? What are the chances that they care,
> > and provide accurate information to a random person?
Are you suggesting we'd provide innacurate information to a random person?
>
> AMD would need to confirm it. IOMMU groups are based on hardware advertised
> isolation via the PCIe ACS capability. Without this, or a device specific
> quirk to take its place, IOMMU groups must assume that peer-to-peer between
> functions of a multi-function device is possible and therefore that the
> devices are not isolated. Chances are that this new chipset in your system
> is taking the exact same ASICs that were deemed not to do peer-to-peer on
> previous chipsets, but we need that confirmation from AMD. Alex Deucher
> (see MAINTAINERS) may have contacts available that can make that statement.
I don't have an answer for you offhand. Let me do some digging and get you an
answer.
>
> > > There is an ACS override patch
> >
> > I already ran across it...
> > https://bugzilla.redhat.com/show_bug.cgi?id=1113399
> > Would I be any worse off using this, compared to the old kvm pci-assign
> > method?
>
> I think the path forward is to get confirmation from AMD that these function
> are isolated from each other and add quirks to the kernel. Then you won't
> have the device dependencies in vfio-pci. The override patch allows you to
> do that with just a kernel boot parameter. There's no gurantee that
> pci-assign will ever be fixed since it's being phased out.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (9 preceding siblings ...)
2014-08-08 2:48 ` bugzilla-daemon
@ 2014-08-08 10:19 ` bugzilla-daemon
2014-08-12 9:36 ` bugzilla-daemon
` (11 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-08 10:19 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #11 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Joel Schopp from comment #10)
> > How would I go about confirming that? What are the chances that they care,
> > and provide accurate information to a random person?
>
> Are you suggesting we'd provide innacurate information to a random person?
Yes, that's my experience with the "customer support" for desktop hardware.
Of course cutting support out of the equation and asking engineers directly is
likely to give better results, that didn't occur to me at first.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (10 preceding siblings ...)
2014-08-08 10:19 ` bugzilla-daemon
@ 2014-08-12 9:36 ` bugzilla-daemon
2014-08-12 10:30 ` bugzilla-daemon
` (10 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 9:36 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
Joerg Roedel <joro@8bytes.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joro@8bytes.org
--- Comment #12 from Joerg Roedel <joro@8bytes.org> ---
Created attachment 146311
--> https://bugzilla.kernel.org/attachment.cgi?id=146311&action=edit
Possible fix as a patch against v3.13
Hi Marti,
Can you please test this patch? I think it should fix the issue.
Thanks, Joerg
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (11 preceding siblings ...)
2014-08-12 9:36 ` bugzilla-daemon
@ 2014-08-12 10:30 ` bugzilla-daemon
2014-08-12 10:42 ` bugzilla-daemon
` (9 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 10:30 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #13 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Joerg Roedel from comment #12)
> Thanks, Joerg
Indeed. Thanks, Joerg. And thanks everyone else too, you have been very
helpful!
I didn't have v3.13 sources handy, but I applied the attachment 146311 patch to
3.16.0 and it fixes the problem. (I verified that unpatched 3.16.0 also
crashes).
I can start & shut down the VM multiple times without crashing the host and PCI
passthrough works as expected.
Feel free to add
Tested-by: Marti Raudsepp <marti@juffo.org>
(In reply to Alex Williamson from comment #7)
> Note that it's not required to assign all the devices, they simply need to
> be detached from host drivers (ie. bound to pci-stub or vfio-pci).
This approach also works; I think I will go this route for the production
setup. Seems that we don't actually need any of the devices in the same IOMMU
group.
(In reply to Joel Schopp from comment #10)
> > AMD would need to confirm it.
>
> I don't have an answer for you offhand. Let me do some digging and get you
> an answer.
I am sorry if I sounded frustrated or arrogant earlier. Any update on this?
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (12 preceding siblings ...)
2014-08-12 10:30 ` bugzilla-daemon
@ 2014-08-12 10:42 ` bugzilla-daemon
2014-08-12 14:53 ` bugzilla-daemon
` (8 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 10:42 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #14 from Joerg Roedel <joro@8bytes.org> ---
Hi Marti,
> Indeed. Thanks, Joerg. And thanks everyone else too, you have been very
> helpful!
>
> I didn't have v3.13 sources handy, but I applied the attachment 146311
> I can start & shut down the VM multiple times without crashing the host and
> PCI passthrough works as expected.
>
> Feel free to add
> Tested-by: Marti Raudsepp <marti@juffo.org>
Thanks for testing the fix, I will send it upstream once the merge window is
over -rc1 is released. I also added a stable tag so it gets backported.
Joerg
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (13 preceding siblings ...)
2014-08-12 10:42 ` bugzilla-daemon
@ 2014-08-12 14:53 ` bugzilla-daemon
2014-08-12 15:09 ` bugzilla-daemon
` (7 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 14:53 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #15 from Joel Schopp <joel.schopp@amd.com> ---
> (In reply to Joel Schopp from comment #10)
> > > AMD would need to confirm it.
> >
> > I don't have an answer for you offhand. Let me do some digging and get you
> > an answer.
>
> I am sorry if I sounded frustrated or arrogant earlier. Any update on this?
It's not clear to me which devices were being put in the same group. Here's
some of my notes on your lspci output
lspci -vt
-[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1422
+-00.2 Advanced Micro Devices, Inc. [AMD] Device 1423
+-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 200
Series]
+-01.1 Advanced Micro Devices, Inc. [AMD/ATI] Device 1308
+-02.0 Advanced Micro Devices, Inc. [AMD] Device 1424
+-03.0 Advanced Micro Devices, Inc. [AMD] Device 1424
+-04.0 Advanced Micro Devices, Inc. [AMD] Device 1424
+-10.0 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller
+-10.1 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller
These xhci controllers are isolated from from the other devices, I would need
some more detail on which variant you are running to determine if they are
isolated from eachother, they probably aren't.
+-11.0 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI
mode]
The sata controller is isolated from the other devices
+-12.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
+-12.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller
This pair of OHCI/EHCI controllers are together isolated from the other devices
+-13.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
+-13.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller
This pair of OHCI/EHCI controllers are together isolated from the other devices
+-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
+-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller
+-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller
+-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but they
are isolated from the other devices I have identified.
+-14.4-[01]----05.0 Dialogic Corporation PRI
The legacy PCI should be isolated from the other devices identified. Not sure
what is going on here.
+-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
This OHCI Controller should also be isolated from the other devices.
+-15.0-[02]--
+-15.2-[03]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller
Is this in a PCI-e slot or otherwise attached to the PCI-e?
+-15.3-[04]----00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet
Is this in a PCI-e slot or otherwise attached to the PCI-e?
+-18.0 Advanced Micro Devices, Inc. [AMD] Device 141a
+-18.1 Advanced Micro Devices, Inc. [AMD] Device 141b
+-18.2 Advanced Micro Devices, Inc. [AMD] Device 141c
+-18.3 Advanced Micro Devices, Inc. [AMD] Device 141d
+-18.4 Advanced Micro Devices, Inc. [AMD] Device 141e
\-18.5 Advanced Micro Devices, Inc. [AMD] Device 141f
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (14 preceding siblings ...)
2014-08-12 14:53 ` bugzilla-daemon
@ 2014-08-12 15:09 ` bugzilla-daemon
2014-08-12 15:20 ` bugzilla-daemon
` (6 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 15:09 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #16 from Alex Williamson <alex.williamson@redhat.com> ---
(In reply to Joel Schopp from comment #15)
> > (In reply to Joel Schopp from comment #10)
> > > > AMD would need to confirm it.
> > >
> > > I don't have an answer for you offhand. Let me do some digging and get you
> > > an answer.
> >
> > I am sorry if I sounded frustrated or arrogant earlier. Any update on this?
>
> It's not clear to me which devices were being put in the same group. Here's
> some of my notes on your lspci output
Marti, the output of 'find /sys/kernel/iommu_groups' would be useful here.
I'll try to help based on what I think is happening...
> lspci -vt
> -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1422
> +-00.2 Advanced Micro Devices, Inc. [AMD] Device 1423
> +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7
> 200 Series]
> +-01.1 Advanced Micro Devices, Inc. [AMD/ATI] Device 1308
> +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1424
> +-03.0 Advanced Micro Devices, Inc. [AMD] Device 1424
> +-04.0 Advanced Micro Devices, Inc. [AMD] Device 1424
> +-10.0 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller
> +-10.1 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller
>
> These xhci controllers are isolated from from the other devices, I would
> need some more detail on which variant you are running to determine if they
> are isolated from eachother, they probably aren't.
10.0 & 10.1 will typically be grouped together due to lack of ACS. This is
usually not a problem.
> +-11.0 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller
> [AHCI mode]
> The sata controller is isolated from the other devices
Yep, and it's a single function device so IOMMU groups should be ok.
> +-12.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
> +-12.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller
> This pair of OHCI/EHCI controllers are together isolated from the other
> devices
Yep, same as above.
> +-13.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
> +-13.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller
> This pair of OHCI/EHCI controllers are together isolated from the other
> devices
Yep
> +-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> +-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller
> +-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller
> +-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
> I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but
> they are isolated from the other devices I have identified.
>
>
> +-14.4-[01]----05.0 Dialogic Corporation PRI
> The legacy PCI should be isolated from the other devices identified. Not
> sure what is going on here.
>
> +-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
> This OHCI Controller should also be isolated from the other devices.
All of the above will be grouped together, this is the problem. Since none of
these functions support ACS, IOMMU groups assume that peer-to-peer between
functions is possible. If 14.4 and 14.5 are truly isolated from the rest of
the package then we should have quirks to support that. This whole block is an
update or the quirk already shown in comment 7.
> +-15.0-[02]--
> +-15.2-[03]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed
> USB Host Controller
> Is this in a PCI-e slot or otherwise attached to the PCI-e?
>
> +-15.3-[04]----00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet
> Is this in a PCI-e slot or otherwise attached to the PCI-e?
I would guess 15.x are all PCIe root ports, hopefully with ACS support.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (15 preceding siblings ...)
2014-08-12 15:09 ` bugzilla-daemon
@ 2014-08-12 15:20 ` bugzilla-daemon
2014-09-01 9:30 ` bugzilla-daemon
` (5 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-08-12 15:20 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #17 from Marti Raudsepp <marti@juffo.org> ---
It's an ASRock FM2A88X Extreme6+ motherboard with the AMD A88X (Bolton-D4)
chipset.
There are 12 IOMMU groups on the system. The problematic group for me is number
9 because the legacy PCI bridge (14.4) gets mixed in with other southbridge
devices (all 14.*).
/sys/kernel/iommu_groups/0/devices:
0000:00:00.0 -> ../../../../devices/pci0000:00/0000:00:00.0
/sys/kernel/iommu_groups/1/devices:
0000:00:01.0 -> ../../../../devices/pci0000:00/0000:00:01.0
0000:00:01.1 -> ../../../../devices/pci0000:00/0000:00:01.1
/sys/kernel/iommu_groups/2/devices:
0000:00:02.0 -> ../../../../devices/pci0000:00/0000:00:02.0
/sys/kernel/iommu_groups/3/devices:
0000:00:03.0 -> ../../../../devices/pci0000:00/0000:00:03.0
/sys/kernel/iommu_groups/4/devices:
0000:00:04.0 -> ../../../../devices/pci0000:00/0000:00:04.0
/sys/kernel/iommu_groups/5/devices:
0000:00:10.0 -> ../../../../devices/pci0000:00/0000:00:10.0
0000:00:10.1 -> ../../../../devices/pci0000:00/0000:00:10.1
/sys/kernel/iommu_groups/6/devices:
0000:00:11.0 -> ../../../../devices/pci0000:00/0000:00:11.0
/sys/kernel/iommu_groups/7/devices:
0000:00:12.0 -> ../../../../devices/pci0000:00/0000:00:12.0
0000:00:12.2 -> ../../../../devices/pci0000:00/0000:00:12.2
/sys/kernel/iommu_groups/8/devices:
0000:00:13.0 -> ../../../../devices/pci0000:00/0000:00:13.0
0000:00:13.2 -> ../../../../devices/pci0000:00/0000:00:13.2
/sys/kernel/iommu_groups/9/devices:
0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0
0000:00:14.1 -> ../../../../devices/pci0000:00/0000:00:14.1
0000:00:14.2 -> ../../../../devices/pci0000:00/0000:00:14.2
0000:00:14.3 -> ../../../../devices/pci0000:00/0000:00:14.3
0000:00:14.4 -> ../../../../devices/pci0000:00/0000:00:14.4
0000:00:14.5 -> ../../../../devices/pci0000:00/0000:00:14.5
0000:01:05.0 -> ../../../../devices/pci0000:00/0000:00:14.4/0000:01:05.0
[When I plug in a card to the other legacy PCI slot, it also appears here
as
pci0000:00/0000:00:14.4/0000:01:06.0]
/sys/kernel/iommu_groups/10/devices:
0000:00:15.0 -> ../../../../devices/pci0000:00/0000:00:15.0
0000:00:15.2 -> ../../../../devices/pci0000:00/0000:00:15.2
0000:00:15.3 -> ../../../../devices/pci0000:00/0000:00:15.3
0000:03:00.0 -> ../../../../devices/pci0000:00/0000:00:15.2/0000:03:00.0
0000:04:00.0 -> ../../../../devices/pci0000:00/0000:00:15.3/0000:04:00.0
/sys/kernel/iommu_groups/11/devices:
0000:00:18.0 -> ../../../../devices/pci0000:00/0000:00:18.0
0000:00:18.1 -> ../../../../devices/pci0000:00/0000:00:18.1
0000:00:18.2 -> ../../../../devices/pci0000:00/0000:00:18.2
0000:00:18.3 -> ../../../../devices/pci0000:00/0000:00:18.3
0000:00:18.4 -> ../../../../devices/pci0000:00/0000:00:18.4
0000:00:18.5 -> ../../../../devices/pci0000:00/0000:00:18.5
(In reply to Joel Schopp from comment #15)
> It's not clear to me which devices were being put in the same group. Here's
> some of my notes on your lspci output
Other than the 14.* devices everything seems to be as you describe.
> +-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> +-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller
> +-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller
> +-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
> I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but
> they are isolated from the other devices I have identified.
Ok, that's not a problem.
> +-14.4-[01]----05.0 Dialogic Corporation PRI
> The legacy PCI should be isolated from the other devices identified. Not
> sure what is going on here.
Yep, currently shares group 9.
> +-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller
> This OHCI Controller should also be isolated from the other devices.
Also shares group 9.
> +-15.0-[02]--
> +-15.2-[03]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed
> USB Host Controller
> Is this in a PCI-e slot or otherwise attached to the PCI-e?
Nope, this is integrated on the motherboard. The only used PCI slot is the
Dialogic card.
> +-15.3-[04]----00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet
> Is this in a PCI-e slot or otherwise attached to the PCI-e?
Integrated Ethernet.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (16 preceding siblings ...)
2014-08-12 15:20 ` bugzilla-daemon
@ 2014-09-01 9:30 ` bugzilla-daemon
2014-09-09 7:39 ` bugzilla-daemon
` (4 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-09-01 9:30 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #18 from Joerg Roedel <joro@8bytes.org> ---
The fix is now upstream and part of Linux v3.17-rc2.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (17 preceding siblings ...)
2014-09-01 9:30 ` bugzilla-daemon
@ 2014-09-09 7:39 ` bugzilla-daemon
2014-09-09 14:58 ` bugzilla-daemon
` (3 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-09-09 7:39 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #19 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Joel Schopp from comment #15)
> It's not clear to me which devices were being put in the same group.
Hi Joel, any updates on this? I posted my IOMMU groups in comment #17 in case
you missed it.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (18 preceding siblings ...)
2014-09-09 7:39 ` bugzilla-daemon
@ 2014-09-09 14:58 ` bugzilla-daemon
2014-09-09 15:25 ` bugzilla-daemon
` (2 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-09-09 14:58 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #20 from Joel Schopp <joel.schopp@amd.com> ---
What updates are you looking for? Joerg's fix is now upstream.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (19 preceding siblings ...)
2014-09-09 14:58 ` bugzilla-daemon
@ 2014-09-09 15:25 ` bugzilla-daemon
2014-10-02 13:30 ` bugzilla-daemon
2014-10-10 15:58 ` bugzilla-daemon
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-09-09 15:25 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #21 from Marti Raudsepp <marti@juffo.org> ---
(In reply to Joel Schopp from comment #20)
> What updates are you looking for? Joerg's fix is now upstream.
Yes, but there's still the issue with southbridge component isolation. You
requested more information from me in comment #15 that I provided in comment
#17.
For background see comment #9 from Alex Williamson:
> AMD would need to confirm it. IOMMU groups are based on hardware advertised
> isolation via the PCIe ACS capability. Without this, or a device specific
> quirk to take its place, IOMMU groups must assume that peer-to-peer between
> functions of a multi-function device is possible and therefore that the
> devices are not isolated. [...]
> I think the path forward is to get confirmation from AMD that these function
> are isolated from each other and add quirks to the kernel. Then you won't
> have the device dependencies in vfio-pci. The override patch allows you to
> do that with just a kernel boot parameter. There's no gurantee that
> pci-assign will ever be fixed since it's being phased out.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (20 preceding siblings ...)
2014-09-09 15:25 ` bugzilla-daemon
@ 2014-10-02 13:30 ` bugzilla-daemon
2014-10-10 15:58 ` bugzilla-daemon
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-10-02 13:30 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #22 from Marti Raudsepp <marti@juffo.org> ---
Since I did not get further confirmation from Mr. Schopp, I decided to push it
and submit a patch: https://lkml.org/lkml/2014/10/2/223
The phrases "Not sure what is going on here" and "should also be isolated" in
comment #15 don't inspire much confidence, but I have not managed to obtain
more concrete statements.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug 81841] amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
2014-08-07 14:45 [Bug 81841] New: amd-iommu: kernel BUG & lockup after shutting down KVM guest using PCI passthrough/PCIe bridge bugzilla-daemon
` (21 preceding siblings ...)
2014-10-02 13:30 ` bugzilla-daemon
@ 2014-10-10 15:58 ` bugzilla-daemon
22 siblings, 0 replies; 24+ messages in thread
From: bugzilla-daemon @ 2014-10-10 15:58 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=81841
Marti Raudsepp <marti@juffo.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #23 from Marti Raudsepp <marti@juffo.org> ---
Closing bug, ACS patch merged to mainline Linux:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3587e625fe24a2d1cd1891fc660c3313151a368c
Thanks Joerg.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 24+ messages in thread