Re: [Xen-users] HVM DomU+Dom0 crash with PCI USB passthrough

[Gordan Bobic <gordan@xxxxxxxxxx>]

On Wed, 31 Jul 2013 15:49:02 +0200, Gustav Sorenson 
<gu.sorenson@xxxxxxxxx> wrote:
> Hello everyone,
>
> ultimately, I'm trying to get VGA passthrough, ideally with the AMD
> A10 integrated graphics, to work. My mainboard is an ASRock FM2A75
> Pro4, which supports IOMMU.
> I had started a thread on July 14 (see here:
> http://lists.xen.org/archives/html/xen-users/2013-07/msg00172.html ).
> Since then, I have been given an old PCIe card that identifies itself
> as "ATI RV515 [Radeon X1300]" in lspci (it's manufactured by MSI, but
> from physical inspection, I couldn't tell any further details, like
> model numer.)
> Now, I again tried to make VGA passthrough work, but failed before I
> could really attempt it:
I don't think X series Radeon cards are supported. I could be wrong,
but I think only Radeon HD4xxx and later cards are known to work
with VGA passthrough (of the ATI cards at least).

> I installed a Win7 x64 DomU from scratch, which worked fine.
> However, when I try to access a pendrive from a passed-through USB
> controller in DomU, DomU hangs. In Dom0, when I press one button on
> the keyboard, it acts as if I kept pushing the button down and never
> releasing it. Other than that, I'm unable to do anything in Dom0. 
> WiFi
> seems also to be lost.
> This keeps happening to me. Interestingly though, the first time I
> tried today, I had no issues at all, but no luck since then.
I also had various lockups (dom0 and domU) seemingly related to
PCI passthrough of USB controllers. Often just before the
crash there would be an interrupt error like this:

kernel: irq 16: nobody cared (try booting with the "irqpoll" option)
kernel: Pid: 0, comm: swapper/0 Tainted: PF          O 
3.9.9-1.el6xen.x86_64 #1
kernel: Call Trace:
kernel: <IRQ>  [<ffffffff810d418d>] __report_bad_irq+0x3d/0xe0
kernel: [<ffffffff810d4386>] note_interrupt+0x156/0x210
kernel: [<ffffffff810d1bb9>] handle_irq_event_percpu+0xc9/0x210
kernel: [<ffffffff810d1d41>] handle_irq_event+0x41/0x70
kernel: [<ffffffff810d4ab9>] handle_fasteoi_irq+0x59/0xf0
kernel: [<ffffffff81302a00>] __xen_evtchn_do_upcall+0x240/0x380
kernel: [<ffffffff81302b7f>] xen_evtchn_do_upcall+0x2f/0x50
kernel: [<ffffffff8155d17e>] xen_do_hypervisor_callback+0x1e/0x30
kernel: <EOI>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
kernel: [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
kernel: [<ffffffff8100a2a0>] ? xen_safe_halt+0x10/0x20
kernel: [<ffffffff8101d166>] ? default_idle+0x46/0x100
kernel: [<ffffffff8101ca99>] ? cpu_idle+0xd9/0x120
kernel: [<ffffffff8153acc5>] ? rest_init+0x75/0x80
kernel: [<ffffffff81803200>] ? start_kernel+0x40e/0x41b
kernel: [<ffffffff81802c10>] ? repair_env_string+0x5b/0x5b
kernel: [<ffffffff818025f1>] ? x86_64_start_reservations+0x2a/0x2c
kernel: [<ffffffff818065ae>] ? xen_start_kernel+0x56e/0x570
kernel: handlers:
kernel: [<ffffffff813caac0>] usb_hcd_irq
kernel: Disabling IRQ #16

What I eventually noticed was that this only seemed to happen
when passing through USB devices that happened to share an
IRQ with something else (in my case it was various ICH10
devices sharing interrupts, USB and SMBus).

I am running 2 GPU passthrough VMs on a single host, and
needed to pass a set of USB ports to each domU. Unfortunately,
I could only find one set of ports (2 ports one PCI device)
that didn't result in using a device with a shared IRQ.

Thankfully, my mobo also comes with a separate USB 3
controller that is on a unique IRQ, so I passed this
to the 2nd VM and I haven't had a lock-up or the above
error since (but it's only been 2 days, so don't hole me
to it quite yet).

Point being - make sure that whatever you are passing
through to domU isn't on a shared interrupt. Also
bear in mind that the binding between the physical port
and the PCI USB controller device can change depending
on what you plug into the port.

> What may be relevant is that I get the following message when I issue
> "xl create xenwin.cfg":
> libxl: error: libxl_pci.c:990:libxl__device_pci_reset: The kernel
> doesn't support reset from sysfs for PCI device 0000:00:12.0
This isn't necessarily a problem - I see this reported for all
my passthrough GPUs. It seems to be mostly harmless.

Gordan

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users