I Konrad, first, thanks for your input and your time, it is much
appreciated.
I understand that those changes are torward the linux kernel, which is used
by xen compilation. I applied the changes and i'm rebuilding Qubes with xen
4.6.1 based on a kernel-4.1.24. Will test the build in the next
On Sun, Jun 26, 2016 at 11:48:44PM +, Thierry Laurion wrote:
> Sorry for the precedent post that was written a bit too fast. Libreboot was
> flashed when I wrote it, which is the equivalent of a having vt-d
> deactivated (iommu=0). Thanks to a user that read this post and wrote to me
>
Sorry for the precedent post that was written a bit too fast. Libreboot was
flashed when I wrote it, which is the equivalent of a having vt-d
deactivated (iommu=0). Thanks to a user that read this post and wrote to me
personally so I could do my mea culpa. Sorry for the precedent misleading
post.
The problem wasn't with xen iommu support but kms/drm and i915 driver.
Passing to the kernel i915.preliminary_hw_support=1 fixes it all :)
Thanks
Le mer. 6 janv. 2016 à 22:11, Thierry Laurion a
écrit :
> Nope. That commit is present in 4.6 and results in x200 being
>>> On 22.12.15 at 19:04, wrote:
> iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1 release,
> thanks to Xen 4.6 :)
>
> The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
> Qubes in the HCL attached to this e-mail. The problem is
Nope. That commit is present in 4.6 and results in x200 being able to boot
xen.
Not having that option makes xen hang at boot.
If present, it works until other vm access pass-through devices, which I'm
not able to troubleshoot even through amt SOL.
See here for debug logs:
Hi all,
iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1 release,
thanks to Xen 4.6 :)
The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
Qubes in the HCL attached to this e-mail. The problem is that when Qubes
launches it's netvm which uses IOMMU to talk to