[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] VGA PASSTHROUGH not working :(



Oh you are right with pciback.

Jason, I agree with him. If you can passthrough your igp, a lot of people will like to know what you did for.

I am working on XenGT, build kernel is OK,  build xen is OK, gvt modules are loaded. Tomorrow I try a guest with vgt enabled.

See you.



Envoyé depuis mon smartphone Samsung Galaxy.
-------- Message d'origine --------
De : sm8ax1@xxxxxxxxxxx
Date : 16/05/2016 18:12 (GMT+01:00)
À : xen-users@xxxxxxxxxxxxx
Objet : Re: [Xen-users] VGA PASSTHROUGH not working :(

I wasn't aware of the intel_iommu=on parameter (thanks for the tip!), and I'm surprised that something like this needs to be explicitly enabled, but I found this thread

https://unix.stackexchange.com/questions/56777/enabling-iommu-in-the-kernel-for-graphics-card-pass-through

which mentions these parameters worth trying also (and a quite a lot of other related information)

  • iommu=memmaper
  • iommu=soft
  • vga=normal
  • vesa=0

As "Ray" noted in another thread, you should try `grep vmx /proc/cpuinfo` while booted into regular Linux to see if VT-d support shows up. Something like this might need to be enabled in the BIOS or kernel configuration before the OS can recognize it. Jason, you might also want to post `xl info` because that might indicate whether the hypervisor recognizes the IOMMU, if someone from the mailing list knows how to decipher the output.

I also wasn't aware of the "pci_stub" parameter, and this is probably more effective than blacklisting the driver module. Do note however that http://wiki.xen.org/wiki/Xen_PCI_Passthrough mentions

"pci-stub can be used only with Xen HVM guest PCI passthru, so it's recommended to use pciback instead, which works for both PV and HVM guests."

I think the parameter is "xen_pciback.hide=0:00.0" with the number of your graphics card as ouputted by `lspci`.

Jason, if you are successful in passing through your integrated Intel graphics at some point, please do follow-up on what worked (xl.cfg(5) file, Dom0 cmdline, etc) since this seems like something a lot of users have trouble with.

Quoting De Coro Guillaume <guillaumedecoro@xxxxxxxxx>:

Hi,

I'm not a great user of xen but I known several things. sm8ax1 is right. It seems you are missing IOMMU. Don't forget to add "intel_iommu=on" in your grub default. If it works you can see that in your dmesg:
[    0.000000] DMAR: IOMMU enabled
[    0.078793] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.865169] iommu: Adding device 0000:00:00.0 to group 0
[    0.865179] iommu: Adding device 0000:00:02.0 to group 1
[    0.865194] iommu: Adding device 0000:00:14.0 to group 2
[    0.865204] iommu: Adding device 0000:00:14.2 to group 2
[    0.865215] iommu: Adding device 0000:00:16.0 to group 3
[    0.865225] iommu: Adding device 0000:00:17.0 to group 4
[    0.865243] iommu: Adding device 0000:00:1c.0 to group 5
[    0.865257] iommu: Adding device 0000:00:1c.2 to group 5
[    0.865280] iommu: Adding device 0000:00:1f.0 to group 6
[    0.865294] iommu: Adding device 0000:00:1f.2 to group 6
[    0.865303] iommu: Adding device 0000:00:1f.3 to group 6
[    0.865312] iommu: Adding device 0000:00:1f.4 to group 6
[    0.865321] iommu: Adding device 0000:00:1f.6 to group 6
[    0.865329] iommu: Adding device 0000:01:00.0 to group 5
[    0.865338] iommu: Adding device 0000:02:00.0 to group 5


and about DMAR:

[    0.000000] ACPI: DMAR 0x00000000A52B3000 0000A8 (v01 INTEL  SKL      00000001 INTL 00000001)
[    0.000000] DMAR: IOMMU enabled
[    0.078747] DMAR: Host address width 39
[    0.078751] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.078769] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e3ff0505e
[    0.078775] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.078781] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462 ecap f050da
[    0.078786] DMAR: RMRR base: 0x000000a4eff000 end: 0x000000a4f1efff
[    0.078789] DMAR: RMRR base: 0x000000a5800000 end: 0x000000a7ffffff
[    0.078793] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.078796] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.078799] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.078801] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    0.080255] DMAR-IR: Enabled IRQ remapping in xapic mode
[    0.864755] DMAR: No ATSR found
[    0.864868] DMAR: dmar0: Using Queued invalidation
[    0.864992] DMAR: dmar1: Using Queued invalidation
[    0.865000] DMAR: Setting RMRR:
[    0.865022] DMAR: Setting identity map for device 0000:00:02.0 [0xa5800000 - 0xa7ffffff]
[    0.865037] DMAR: Setting identity map for device 0000:00:14.0 [0xa4eff000 - 0xa4f1efff]
[    0.865047] DMAR: Prepare 0-16MiB unity mapping for LPC
[    0.865093] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.865112] DMAR: Intel(R) Virtualization Technology for Directed I/O


It's important not to claim your passthroughed hardware by dom0. Just use "pci_stub" parameters in your grub default. After that, your command "xl pci-assignable-list" will give your video card available.

About IGD passthrough, I'm working on it without success for monthes. Maybe I'm wrong, but XenGT build fail for me. I'm using an Intel i3 6100T with Intel HD 530. I saw that Xen 4.7 will handle some igd passthrough parameters. So wait and see... and try it :)

Ciao.

Le 14/05/2016 14:56, sm8ax1@xxxxxxxxxxx a écrit :

 

Well, it looks to me like you don't have an IOMMU. You can check your Intel processor http://ark.intel.com/ and look for "VT-d" support. There is probably a similar site for AMD, but they call it "IOMMU" support; same thing just different names. There might also be some way to check through `lshw` or `/proc/cpuinfo` or the like, but I don't know for sure.

The wiki mentions that generic PCI passthrough might still work on some graphics cards, even without an IOMMU, but I imagine your chances are pretty slim. Something to try perhaps is setting up your HVM to automatically start when the system is booted, with generic PCI passthrough enabled, and blacklist the module on the Dom0 and reboot. In theory this prevents the Dom0 driver from interfering with the HVM's configuration of the graphics card, but once again, it might work or it might not.

http://wiki.xen.org/wiki/Xen_VGA_Passthrough
http://wiki.xen.org/wiki/VTdHowTo

If that doesn't work, your options are buy a new PC/processor with an IOMMU, or use VNC, Spice, SDL, GTK, etc. with userspace frontends in the Dom0. Spice with the QXL video driver is likely to give you the best performance, but even it won't compete with that of VGA passthrough.

http://wiki.xen.org/wiki/SPICE_support_in_Xen

If you go the route of upgrading your hardware, XenGT (now called "GVT-v for Xen") is something else to look into. The idea behind it is to allow multiple VMs to simultaneously use VGA passthrough in a safe and performant manner by creating multiple virtual graphics cards at the hardware level. At least as of Jan 2015, XenGT is being developed out-of-tree, but I haven't followed up on it as to whether it's been merged (or abandoned). If I recall correctly, this is supported on Intel 6th generation and newer processors with Intel HD 6000+ graphics, but you should definitely double check that.

http://wiki.xen.org/wiki/XenGT
https://blog.xenproject.org/2014/03/11/xen-graphics-virtualization-xengt/
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-LinuxCollaborationSummit-final_1.pdf

There used to be something called "Paravirtualized DRM", which probably worked like the paravirtualized framebuffer, only using the newer and faster Linux DRM API. This, I guess, would have allowed multiple rendering clients across multiple VMs to directly render their window contents just as they would on baremetal (with the PV DRM driver acting as a shim), without any kind of VGA/PCI passthrough. Unfortunately this effort has been abandoned, and I've been unable to track down the author or even the original code.

http://wiki.xen.org/wiki/Paravirtualized_DRM


Quoting Jason Long <hack3rcon@xxxxxxxxx>:

Hello.
I want to use my VGA in VM that running Windows 7, My VGA information is :
 
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device 8354
Kernel driver in use: nouveau
Kernel modules: nouveau
 
And :
 
[root@localhost ~]# xl pci-assignable-list 
[root@localhost ~]# 
 
And I added below lines to my VM config file :
 
gfx_passthru=0
acpi=1
pci=['01:00.0 ']
 
but when I want fire my VM, It show me below error :
 
libxl: error: libxl_pci.c:1089:libxl__device_pci_add: PCI device 0000:01:00.0 cannot be assigned - no IOMMU?
libxl: error: libxl_create.c:1405:domcreate_attach_pci: libxl_device_pci_add failed: -1
libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 3365 for destroy of domain 3
 
How can I solve it?


 



-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas!   15GB disk space!
Commercial and Bulk Mail Options!



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






-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas!   15GB disk space!
Commercial and Bulk Mail Options!

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.