Le mar. 26 janv. 2016 à 21:10, Thierry Laurion <thierry.laur...@gmail.com> 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 < > marma...@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.laur...@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 <http://xenbits.xen.org/docs/4.3-testing/misc/crashdb.txt>) 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?
xendebug.output
Description: Binary data
lspci.verbose
Description: Binary data
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
