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 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. 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 I''m running kernel 3.10.1 on Mint 15, with xen sources checked out from git on July 27, commit 704302ce9404c73cfb687d31adcf67094ab5bb53. Kernel config: http://pastebin.com/LVsKEWdM DomU config: http://pastebin.com/tHwQHUiA What can I do to resolve this? Any help is highly appreciated, and I''m very willing to help debug this should this not be due to a configuration error.
On Wed, 31 Jul 2013 15:49:02 +0200, Gustav Sorenson <gu.sorenson@gmail.com> 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.0This isn''t necessarily a problem - I see this reported for all my passthrough GPUs. It seems to be mostly harmless. Gordan
On Wed, Jul 31, 2013 at 9:17 AM, Gordan Bobic <gordan@bobich.net> wrote: <snip>> 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 >For reference, I also get that same error message on my install - From running lspci on my main system: 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller This is the USB controller I pass through to a Windows 7 domU, and it''s been working fine (for the most part; on rare occasions, my kvm isn''t detected correctly, but then I just replug it in and it works) One other thing you may want to try is to try using the traditional mode device model; add the following into your domU config: device_model_version = "qemu-xen-traditional" Regards, David _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 31 Jul 2013 10:24:34 -0500, David Sutton <kantras@gmail.com> wrote:> On Wed, Jul 31, 2013 at 9:17 AM, Gordan Bobic wrote: > > 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. > > For reference, I also get that same error message on my install - > From > running lspci on my main system: > > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0/SB8x0/SB9x0 USB OHCI0 Controller > 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0/SB8x0/SB9x0 USB EHCI Controller > > This is the USB controller I pass through to a Windows 7 domU, and > it''s been working fine (for the most part; on rare occasions, my kvm > isn''t detected correctly, but then I just replug it in and it works) > > One other thing you may want to try is to try using the traditional > mode device model; add the following into your domU config: > > device_model_version = "qemu-xen-traditional"Yes, forgot to mention that, I am only using traditional at the moment, which may or may not make any difference. Gordan
Hello,> 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 wafs various ICH10 > devices sharing interrupts, USB and SMBus).is there a way I can see which devices share IRQs? Is it possible to change the IRQ mappings if they are unconvenient?> 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.I''m not sure I understood. Are you saying that when I plugin in device X in the USB port A, it could get handled by a different PCI device than if I had plugged in device Y into A instead? I just installed a USB2 PCI controller card, manufactured by LogiLink and advertising a NEC Chip. It appears in lspci as 01:06.0 USB controller: NEC Corporation OHCI USB Controller (rev 41) 01:06.1 USB controller: NEC Corporation OHCI USB Controller (rev 41) 01:06.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 02) I assigned all three of these to pciback, rebooted, assigned them to the DomU and launched it. However, every time I try to start the DomU with the new USB controller attached, both Dom0 and DomU hang after a few seconds (this surely is not enough time for DomU to finish booting, but maybe it started doing that.) What may be the reason for this? My mainboard has three PCI slots. Could it make a difference which slot I put the card into? I will try qemu-xen-traditional later. Thank you very much, Gordan and David!
On Wed, 31 Jul 2013 17:54:26 +0200, Gustav Sorenson <gu.sorenson@gmail.com> wrote:> Hello, > >> 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 wafs various ICH10 >> devices sharing interrupts, USB and SMBus). > > is there a way I can see which devices share IRQs? Is it possible to > change the IRQ mappings if they are unconvenient? > >> 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. > > I''m not sure I understood. Are you saying that when I plugin in > device > X in the USB port A, it could get handled by a different PCI device > than if I had plugged in device Y into A instead?In a word - yes. On my system (ICH10) some USB controllers don''t correspond to any of the ports on the machine (mapped it out). At the same time, multiple ports can correspond to the same PCI device that is the USB controller. But - if I plug in a USB hub, suddenly the PCI device handling that port changes to one of the ones that didn''t seem to handle any of the physical ports. Weird, I know, but that''s what it seems to be doing.> I just installed a USB2 PCI controller card, manufactured by LogiLink > and advertising a NEC Chip. It appears in lspci as > 01:06.0 USB controller: NEC Corporation OHCI USB Controller (rev 41) > 01:06.1 USB controller: NEC Corporation OHCI USB Controller (rev 41) > 01:06.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller > (rev 02) > I assigned all three of these to pciback, rebooted, assigned them to > the DomU and launched it. However, every time I try to start the DomU > with the new USB controller attached, both Dom0 and DomU hang after a > few seconds (this surely is not enough time for DomU to finish > booting, but maybe it started doing that.)It sounds more like it locks up during initializing the USB driver. My USB3 ports are handled by a NEC controller and it seems to work fine for me.> What may be the reason for this? My mainboard has three PCI slots. > Could it make a difference which slot I put the card into?Plausibly, yes. Can you check lspci -vvv and see if any of those USB devices are sharing an IRQ with anything else on the system? It might also be handy to check the output of lspci -t and see if there is an odd bridging topology in play. Gordan
Hello everyone, I''ve removed the PCI USB controller from one PCI slot and inserted it into another. Still, when trying to boot a DomU, DomU and Dom0 hang. I have also tried passing the PCI USB controller with device_model_version = "qemu-xen-traditional" and this is what I get from xl create xenwin.cfg: Parsing config from xenwin.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eea8 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f000000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003f7 1GB PAGES: 0x0000000000000000 libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to add device: 0000:01:07.0,msitranslate=0,power_mgmt=0 libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to add device: 0000:01:07.1,msitranslate=0,power_mgmt=0 libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to add device: 0000:01:07.2,msitranslate=0,power_mgmt=0 Daemon running with PID 3627 The DomU boots fine, but doesn''t detect the USB controller. If I try to pass one of the motherboard''s USB controllers, 00:12.0 and 00:12.2, I don''t get any such error messages, Windows boots, but in the Device manager complains about a PCI Device being unavailable for use (yellow triangle with Code 28, messages would be something like "Drivers not installed" (translated message, but that''s what it means.)) This is my current lspci -vvv: http://pastebin.com/MBFPd3Kx And this is lspci -t: http://pastebin.com/0Mk5y5db Again, thanks for helping. :)
On 08/01/2013 11:10 AM, Gustav Sorenson wrote:> Hello everyone, > > I''ve removed the PCI USB controller from one PCI slot and inserted it > into another. Still, when trying to boot a DomU, DomU and Dom0 hang. > > I have also tried passing the PCI USB controller with > device_model_version = "qemu-xen-traditional" > and this is what I get from xl create xenwin.cfg: > Parsing config from xenwin.cfg > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000019eea8 > Modules: 0000000000000000->0000000000000000 > TOTAL: 0000000000000000->000000007f000000 > ENTRY ADDRESS: 0000000000100000 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000003f7 > 1GB PAGES: 0x0000000000000000 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.0,msitranslate=0,power_mgmt=0 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.1,msitranslate=0,power_mgmt=0 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.2,msitranslate=0,power_mgmt=0 > Daemon running with PID 3627 > > > The DomU boots fine, but doesn''t detect the USB controller. > > If I try to pass one of the motherboard''s USB controllers, 00:12.0 and > 00:12.2, I don''t get any such error messages, Windows boots, but in > the Device manager complains about a PCI Device being unavailable for > use (yellow triangle with Code 28, messages would be something like > "Drivers not installed" (translated message, but that''s what it > means.))Apologies if this is too obvious, but - you did install the latest driver for that USB controller in domU, right? Gordan
Hello,> Apologies if this is too obvious, but - you did install the latest driver > for that USB controller in domU, right?No apologies needed, I''m happy if people point out things that may seem obvious to them - I might just have forgotten about it, or it may not be obvious to me. In this case though, installing the driver didn''t help. I would have been surprised if it did, since I''ve never had to install a driver for USB2 components on Windows 7 before. Even with the driver installed, I have an unrecognized PCI device in DomU. But that might be something else (from qemu for example.) I assume though that the error messages I posted in the last mail, saying "qemu refused to add device," may be the cause why the USB ports don''t work in DomU. Any ideas what I can do about it? Thanks!
On 08/01/2013 05:52 PM, Gustav Sorenson wrote:> Hello, > >> Apologies if this is too obvious, but - you did install the latest driver >> for that USB controller in domU, right? > > No apologies needed, I''m happy if people point out things that may > seem obvious to them - I might just have forgotten about it, or it may > not be obvious to me. > > In this case though, installing the driver didn''t help. I would have > been surprised if it did, since I''ve never had to install a driver for > USB2 components on Windows 7 before. > Even with the driver installed, I have an unrecognized PCI device in > DomU. But that might be something else (from qemu for example.) > > I assume though that the error messages I posted in the last mail, > saying "qemu refused to > add device," may be the cause why the USB ports don''t work in DomU. > > Any ideas what I can do about it?No idea, sorry - I''m seeing a similar issue with passing through USB devices (as opposed to PCI USB controllers). Gordan
> Hello everyone, > > I''ve removed the PCI USB controller from one PCI slot and inserted it > into another. Still, when trying to boot a DomU, DomU and Dom0 hang. > > I have also tried passing the PCI USB controller with > device_model_version = "qemu-xen-traditional" > and this is what I get from xl create xenwin.cfg: > Parsing config from xenwin.cfg > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000019eea8 > Modules: 0000000000000000->0000000000000000 > TOTAL: 0000000000000000->000000007f000000 > ENTRY ADDRESS: 0000000000100000 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000003f7 > 1GB PAGES: 0x0000000000000000 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.0,msitranslate=0,power_mgmt=0 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.1,msitranslate=0,power_mgmt=0 > libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready > libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to > add device: 0000:01:07.2,msitranslate=0,power_mgmt=0 > Daemon running with PID 3627 > > > The DomU boots fine, but doesn''t detect the USB controller. > > If I try to pass one of the motherboard''s USB controllers, 00:12.0 and > 00:12.2, I don''t get any such error messages, Windows boots, but in > the Device manager complains about a PCI Device being unavailable for > use (yellow triangle with Code 28, messages would be something like > "Drivers not installed" (translated message, but that''s what it > means.)) > > This is my current lspci -vvv: http://pastebin.com/MBFPd3Kx > And this is lspci -t: http://pastebin.com/0Mk5y5db > > > Again, thanks for helping. :)Hello Guatav, I have a Gigabyte board with a similar PCI layout. Passing any of those 00:XX.Y devices doesn''t play terribly well unless you ensure that as much as possible is assigned to pciback; or that at least all of the USB controllers are ;) Anyway, what I *know* works for me is to pass the device...> 03:00.0 USB controller: Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller (prog-if 30 [XHCI])...through to your Windows DomU. Windows 7 _does_not_have_ drivers for this device as there is no USB3 stack. The USB3 drivers from your motherboard mfg''s website (ASRock?) should work to get it installed after it shows up unknown in device manager. Cheers, Andrew Bobulsky
On 08/02/2013 08:17 PM, Andrew Bobulsky wrote:> >> Hello everyone, >> >> I''ve removed the PCI USB controller from one PCI slot and inserted it >> into another. Still, when trying to boot a DomU, DomU and Dom0 hang. >> >> I have also tried passing the PCI USB controller with >> device_model_version = "qemu-xen-traditional" >> and this is what I get from xl create xenwin.cfg: >> Parsing config from xenwin.cfg >> xc: info: VIRTUAL MEMORY ARRANGEMENT: >> Loader: 0000000000100000->000000000019eea8 >> Modules: 0000000000000000->0000000000000000 >> TOTAL: 0000000000000000->000000007f000000 >> ENTRY ADDRESS: 0000000000100000 >> xc: info: PHYSICAL MEMORY ALLOCATION: >> 4KB PAGES: 0x0000000000000200 >> 2MB PAGES: 0x00000000000003f7 >> 1GB PAGES: 0x0000000000000000 >> libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready >> libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to >> add device: 0000:01:07.0,msitranslate=0,power_mgmt=0 >> libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready >> libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to >> add device: 0000:01:07.1,msitranslate=0,power_mgmt=0 >> libxl: error: libxl_exec.c:227:libxl__wait_for_offspring: Device Model not ready >> libxl: error: libxl_pci.c:835:qemu_pci_add_xenstore: qemu refused to >> add device: 0000:01:07.2,msitranslate=0,power_mgmt=0 >> Daemon running with PID 3627 >> >> >> The DomU boots fine, but doesn''t detect the USB controller. >> >> If I try to pass one of the motherboard''s USB controllers, 00:12.0 and >> 00:12.2, I don''t get any such error messages, Windows boots, but in >> the Device manager complains about a PCI Device being unavailable for >> use (yellow triangle with Code 28, messages would be something like >> "Drivers not installed" (translated message, but that''s what it >> means.)) >> >> This is my current lspci -vvv: http://pastebin.com/MBFPd3Kx >> And this is lspci -t: http://pastebin.com/0Mk5y5db >> >> >> Again, thanks for helping. :) > > Hello Guatav, > > I have a Gigabyte board with a similar PCI layout. Passing any of those 00:XX.Y devices doesn''t play terribly well unless you ensure that as much as possible is assigned to pciback; or that at least all of the USB controllers are ;) > > Anyway, what I *know* works for me is to pass the device... > >> 03:00.0 USB controller: Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller (prog-if 30 [XHCI]) > > ...through to your Windows DomU. > > Windows 7 _does_not_have_ drivers for this device as there is no USB3 stack. The USB3 drivers from your motherboard mfg''s website (ASRock?) should work to get it installed after it shows up unknown in device manager.This is pretty much the same thing I''ve found - I had a lot of random lockups passing through south-bridge USB devices, especially if they share interrupts. Switched to passing the discrete USB3 controller, and the problem went away. Gordan