Le mer. 27 janv. 2016 à 00:08, Thierry Laurion a écrit : > Le mar. 26 janv. 2016 à 21:10, Thierry Laurion > a écrit : > >> I just tested freshly compiled xen.gz file produced from patched source, >> as recommended by ktempkin. (Previous post xen.diff attached file got >> applied to disable pmr). >> >> Same behavior was observable with iommu=no-igfx: when net-vm tray icon >> gets rendered (corrupted graphics) and notification are draw on screen, >> system hang without logging any error. >> >> I will compile xen with debugging options. >> >> If you guys have any insight or people I should talk to, please advise. >> It would be greatly appreciated. :) >> >> Thierry >> >> >> Le dim. 24 janv. 2016 18:45, Marek Marczykowski-Górecki < >> marmarek@invisiblethingslab.com> a écrit : >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On Sun, Jan 24, 2016 at 06:21:05PM +0000, Thierry Laurion wrote: >>> > Hi devs! >>> > >>> > XEN devs: >>> > As per short discussion with ktemkin earlier in January in #xen: >>> > >>> > "ktemkin Jan 10, 2016 16:21:50 >>> > This test patch did appear to make the system work, though: >>> > https://gist.github.com/ktemkin/0e81b93654ae800a5609 >>> > >>> > ktemkin Jan 10, 2016 16:24:55 >>> > Only real difference I see between that and the upstream behavior >>> (besides >>> > limiting things to dom0 so things weren't accidentally passed through) >>> is >>> > the call to disable_pmr on line 117 before aborting." >>> > >>> > >>> > >>> > Makes total sense to my early understanding, since it seems that it is >>> said >>> > that vt-d engine gets disabled, but disable_pmr(iommu) function is not >>> > called to enforce. >>> > >>> > What do you think? >>> > >>> > QUBES devs: >>> > I'm still trying to understand how to apply this patch to >>> qubes_builder to >>> > actually build a test iso or xen.gz image and report. All Qubes patches >>> > seem to be applied from git to local directory structure. Looking >>> inside >>> > the code to understand how to generate the provided patch to git can >>> apply >>> > it to local chrooted environment when building. Any documentation you >>> could >>> > point me to would be greatly appreciated, as any feedback to actually >>> fix >>> > the issue stopping this laptop from being a nearly perfect candidate >>> for >>> > Qubes. >>> >>> Actually for testing patched hypervisor, you can build xen the standard >>> way (http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source). And >>> then copy just xen.gz. Qubes-specific patches are only for the >>> toolstack, not the hypervisor. >>> >>> But if you want to build full xen package, simply place patches >>> somewhere in qubes-builder/qubes-src/vmm-xen (patches.misc subdir?) and >>> add them to series.conf. Then execute "make vmm-xen" from qubes-builder >>> directory. >>> >>> > >>> > Thierry >>> > >>> > Le sam. 23 janv. 2016 à 02:37, Thierry Laurion < >>> thierry.laurion@gmail.com> >>> > a écrit : >>> > >>> > > Hey devs, >>> > > >>> > > Thinkpad x200 p8600 laptops have vt-d, vt-x and tpm. They also have >>> intel >>> > > integrated graphics 4 Series (gm45 chipset), supported through i915 >>> driver. >>> > > >>> > > In December, a fix got introduced to Xen 4.6 through iommu=no-igfx >>> switch. >>> > > Before that fix, it was impossible to boot xen without passing >>> iommu=0. >>> > > >>> > > With iommu=no-igfx passed on, Qubes boots xen, kernel, dom0 and domu >>> until >>> > > some graphic rendering is done from a domu to dom0 xserver. >>> > > >>> > > I'm trying to push forward IOMMU support of gm45 chipset here. The >>> problem >>> > > is between i915 and xen iommu support for sure, but there is no >>> crash or >>> > > interesting debugging information given on a serial console. >>> > > >>> > > Any dev help is welcome since that beast and t400 would be excellent >>> Qubes >>> > > candidates once that problem is fixed. I posted in December on the >>> list >>> > > just before Christmas but I guess the timing wasn't right;) >>> > > >>> > > Thanks for your help. >>> > > Thierry >>> > > >>> > >>> >>> >>> >>> - -- >>> Best Regards, >>> Marek Marczykowski-Górecki >>> Invisible Things Lab >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQEcBAEBCAAGBQJWpWIjAAoJENuP0xzK19csmBcH/jAkYioso8K0POq+hIPop9Ft >>> E9h0b964j/jaZsgqofmnZFj8ZA4zI/qr4mQEIuNdk+dUgN69awn/Ffa+/bxTtv0B >>> 7AnCv65s+xMAOn8YHIc/pcwmL1/FymK1NAoVdk4wWXdWhxOW1PdGp+OCvFGFpOd1 >>> L0rWwuY+EAV1UnUmd4OyPBLVh4f5fFG7B4tXnd1LaZ18noeSOaJpj5/o55zuwpgC >>> Fx3CtxtAlMLOpu7W1S/MzC73aOajKpFwoaS4RAMD8/Wby3nvtgcBJ6jmBmmSdn/J >>> 9YUOxO9cflIKjKbqXmYZJFceK1CmGNYhYEjTI8m1K9e+ian3vWa3GOwEfBk1oIo= >>> =F+Eh >>> -----END PGP SIGNATURE----- >>> >> > Here is the output of xen (compiled with debug options in Config.mk and > rules.mk as instucted here > ) debug trace > when launched from grub2 with: > > multiboot /xen-4.6.0-debug.gz placeholder console=none dom0_mem=min:1024M > dom0_mem=max:4096M console_timestamps=datems loglvl=all guest_loglvl=all > sync_console console_to_ring lapic=debug apic_verbosity=debug apic=debug > iommu=no-igfx iommu=debug debug > > module /vmlinuz-4.1.13-8.pvops.qubes.x86_64 placeholder > root=/dev/mapper/qubes_dom0-root ro rd.lvm.lv=qubes_dom0/root > vconsole.font=latarcyrheb-sun16 rd.lvm.lv=qubes_dom0/swap > rd.luks.uuid=luks-blah > > module /initramfs-4.1.13-8.pvops.qubes.x86_64.img > > Any idea? hints? Tips? > Hi all, this is debug trace I have with xen 4.6.0 debug build. Attached files were generated with the single x200 laptop I have that has amt (The only one I have with a VPRO Centrino 2 Inside cpu sticker). Those are the most complete debug traces I was able to generate. 4 use cases: 1-iommu=required (x200_xen_debug-iommu-required.txt) 2-normal boot (x200_xen_debug-normal.txt) 3-iommu=no-igfx (x200_xen_debug-iommu-no_igfx.txt) 4-iommu=0 (x200_xen_debug-no_iommu.txt) 4 different behaviors: 1-hang before xen is functional ("Couldn't enable Interrupt Remapping and iommu=required/force") 2-hang just after vgaarb and drm driver replacement. 3-hang at graphic rendering in dom0 from netvm domu and usbvm domu notifications when everything is ready to go. 4-functional but no netvm and usbvm device isolation Any hint/tips/people to point me at? Thierry