On Monday, August 8, 2016 at 6:20:01 AM UTC+3, Marek Marczykowski-Górecki wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Fri, Aug 05, 2016 at 10:55:02PM +0200, Marek Marczykowski-Górecki > wrote: > > On Fri, Aug 05, 2016 at 01:26:57PM -0700, [email protected] <javascript:> > wrote: > > > > > > > > > On Friday, August 5, 2016 at 12:58:16 AM UTC+3, Marek > Marczykowski-Górecki > > > wrote: > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA256 > > > > > > > > On Thu, Aug 04, 2016 at 01:45:58PM -0700, [email protected] > <javascript:> > > > > wrote: > > > > > Hi, > > > > > > > > > > this is just a heads-up about a preliminary work I've been doing > to get > > > > Xen > > > > > 4.7.0 working on Qubes 3.2 rc2 (mainly motivated to see if any of > the > > > > > massive amount of changes would have any effect on PCI/GPU > passthrough). > > > > > > > > > > VMM-XEN: > > > > > https://github.com/WetwareLabs/qubes-vmm-xen/tree/xen-4.7 > > > > > > > > > > Most changes are straightforward modifications of Qubes patches > > > > > (surrounding lines in original files been changed and this causes > > > > patching > > > > > to fail). Some patches required a little bit more tinkering And > few > > > > changes > > > > > were made to the build process. > > > > > > > > Thanks! It's too late to have it in R3.2, but we surely want Xen 4.7 > in > > > > Qubes 4.0. > > > > > > > > > Also Libvirt, libvchan and gui-daemon needed minor changes: > > > > > > > > > > https://github.com/WetwareLabs/qubes-core-libvirt/tree/xen-4.7 > > > > > > > > Take a look at core3-devel branch on my github - there is already > > > > libvirt 2.0.0. > > > > > > > > > https://github.com/WetwareLabs/qubes-core-vchan-xen > > > > > https://github.com/WetwareLabs/qubes-gui-daemon > > > > > > > > > > > > > > > With these modifications, it builds ok (in Fedora 23 AppVM on > Qubes 3.1) > > > > > and can be installed from ISO. However there's now something wrong > with > > > > > gui-daemon (I suspect): > > > > > VMs will start, but if any application (xterm for example) is > started, > > > > the > > > > > green dot on QubesManager changes to yellow, and no window is > created. > > > > If > > > > > another app is launched, then a window briefly flashes and closes > again. > > > > > Every time this happens, there's this log (in > guid.sys-firewall.log for > > > > > example): > > > > > ErrorHandler: BadValue (integer parameter out of range for > operation) > > > > > Major opcode: 130 (MIT-SHM) > > > > > Minor opcode: 3 (X_ShmPutImage) > > > > > Value: 0x1f5 > > > > > Failed serial number: 88 > > > > > Current serial number: 89 > > > > > > > > Looks like your X server don't have shmoverride preloaded, or its > > > > startup failed. Check stderr of X server - if started from lightdm, > it > > > > will be in /var/log/lightdm/x-0.log. > > > > > > > > > But with qvm-run I can run commands properly in this VM. > > > > > I tried looking into gui-daemon code, but it seems this error is > created > > > > > somewhere else outside of gui-daemon (it's only catched by the > daemon). > > > > > > > > > > Also there this line in libxl-driver.log: > > > > > libxl:error: libxl.c:1840:libxl_console_tty: unable to read > console tty > > > > > path '/local/domain/4/console/tty': Function not implemented. > > > > > > > > > > But this appears at some point during/after boot, and I don't know > if > > > > it's > > > > > related to this bug. > > > > > > > > The same is on Xen 4.6, harmless. > > > > > > > > > I didn't dare to make a pull request on GitHub, since this is > currently > > > > in > > > > > broken state. But if you're moving to use 4.7.0 at some point > (maybe > > > > Qubes > > > > > 4.0?), feel free to use this to avoid duplicate work :) > > > > > > > > :) > > > > > > > > - -- > > > > 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 > > > > > > > > iQEcBAEBCAAGBQJXo7pyAAoJENuP0xzK19csDMcH/10g+19GhEUDCOxuHa64Tg57 > > > > DgQePoZ6PGEVDODoeoL0yeKrbPqGfDFVs2qyoRx0Dy3fHwn40D8O3jtIRfW+FYb+ > > > > MuLV0+1YcY44KSjgl+anGwmyg5yEbQypuM7/d5WClFavOyx0EJxUxWE4lDyoDNxi > > > > NVfK83DnhT2qGOElF3wi7FHsZ9cW0U9u7pAaAqLddw5yj8af+pZaSxkIVcoNTS34 > > > > 6qa8loHcNICc/guzf+wvHEaGovsh5SZjWKtj03PL/Mpt/7QhmxSbrt2t6H4y4imv > > > > mvdWJ0fttCPjseDSd+Jlkv4yKF2kDFOz/U6LWgtlmPFHFFafaazjfkmEx8p7mus= > > > > =QYAU > > > > -----END PGP SIGNATURE----- > > > > > > > > > > Marek, thanks for your advice! > > > > > > I looked more into the shmoverride issue. There's this sequence of > events > > > that cause this: > > > - OS boots. Pass the login screen > > > - shmoverride is loaded ("shmoverride constructor running") > > > - X crashes in 1-2 seconds after login completes and > desktop/QubesManager > > > is shown. > > > This is in Xorg.0.log.old: > > > [ 2285.229] (EE) Backtrace: > > > [ 2285.229] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5978f9] > > > [ 2285.230] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) > [0x7f8cd98b2aaf] > > > [ 2285.230] (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0x1e7) [ > > > 0x7f8cd99c6547] > > > [ 2285.231] (EE) 3: /usr/lib64/xorg/modules/drivers/radeon_drv.so > (_init+ > > > 0x2b07f) [0x7f8cd35b9b9f] > > > [ 2285.231] (EE) 4: /usr/lib64/xorg/modules/libexa.so > (exaMoveOutPixmap+ > > > 0x57fd) [0x7f8cd22be9fd] > > > [ 2285.231] (EE) 5: /usr/lib64/xorg/modules/libexa.so > (exaMoveOutPixmap+ > > > 0x593f) [0x7f8cd22bf81f] > > > [ 2285.231] (EE) 6: /usr/bin/X (miCopyRegion+0x1ab) [0x57341b] > > > [ 2285.231] (EE) 7: /usr/bin/X (miDoCopy+0x466) [0x5739c6] > > > [ 2285.232] (EE) 8: /usr/lib64/xorg/modules/libexa.so > (exaMoveOutPixmap+ > > > 0x3ee5) [0x7f8cd22bc3b5] > > > [ 2285.232] (EE) 9: /usr/bin/X (DamageRegionAppend+0x3551) [0x521611] > > > [ 2285.232] (EE) 10: /usr/bin/X (SyncVerifyFence+0x1d8c) [0x4d3efc] > > > [ 2285.232] (EE) 11: /usr/bin/X (SyncVerifyFence+0x36c5) [0x4d73e5] > > > [ 2285.232] (EE) 12: /usr/bin/X (SendErrorToClient+0x2df) [0x436a3f] > > > [ 2285.232] (EE) 13: /usr/bin/X (remove_fs_handlers+0x453) [0x43aa53] > > > [ 2285.233] (EE) 14: /lib64/libc.so.6 (__libc_start_main+0xf0) [ > > > 0x7f8cd989e580] > > > [ 2285.233] (EE) 15: /usr/bin/X (_start+0x29) [0x424d99] > > > [ 2285.234] (EE) 16: ? (?+0x29) [0x29] > > > [ 2285.234] (EE) > > > [ 2285.234] (EE) Segmentation fault at address 0xffffffffcaa1d7b4 > > > [ 2285.234] (EE) > > > Fatal server error: > > > [ 2285.234] (EE) Caught signal 11 (Segmentation fault). Server > aborting > > > > > > > > > - X is restarted automatically. Back to login screen > > > - shmoverride.so is restarted but it fails because /var/run/shm.id > exists > > > already > > > - Now after login the X stays up and doesn't crash. but GUI operations > on > > > VMs cause the abovementioned BadValue-error described in first post. > > > > > > I forced the shmoverride to overwrite shm.id so it is restarted > correctly, > > > but this causes X to crash and restart always when desktop is reached. > > > > > > I first thought the crash would have something to do with radeon > driver, > > > but the trace changed a bit after modifying shmoverride: > > > [ 709.756] (EE) Backtrace: > > > [ 709.757] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5978f9] > > > [ 709.757] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) > [0x7f13d1b4faaf] > > > [ 709.758] (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0xd5) [ > > > 0x7f13d1c63435] > > > [ 709.758] (EE) 3: /usr/lib64/xorg/modules/libfb.so (fbBlt+0xee) [ > > > 0x7f13cb5d992e] > > > [ 709.759] (EE) 4: /usr/lib64/xorg/modules/libfb.so (fbBltStip+0x26) > [ > > > 0x7f13cb5da716] > > > [ 709.759] (EE) 5: /usr/lib64/xorg/modules/libfb.so > (fbPutZImage+0x1ba) [ > > > 0x7f13cb5df73a] > > > [ 709.759] (EE) 6: /usr/bin/X (DamageRegionAppend+0x3783) [0x521a73] > > > [ 709.760] (EE) 7: /usr/bin/X (SyncVerifyFence+0x1f58) [0x4d40c8] > > > [ 709.760] (EE) 8: /usr/bin/X (SyncVerifyFence+0x36c5) [0x4d73e5] > > > [ 709.760] (EE) 9: /usr/bin/X (SendErrorToClient+0x2df) [0x436a3f] > > > [ 709.760] (EE) 10: /usr/bin/X (remove_fs_handlers+0x453) [0x43aa53] > > > [ 709.761] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf0) [ > > > 0x7f13d1b3b580] > > > [ 709.761] (EE) 12: /usr/bin/X (_start+0x29) [0x424d99] > > > [ 709.762] (EE) 13: ? (?+0x29) [0x29] > > > > > > > > > There were few reports about crashes related to OsLookupColor on the > net, > > > but they were mainly about gfx drivers. But this doesn't explain why > > > there's a crash now but none on 3.2rc2 with identical drivers. Also > none of > > > the Qubes patches I modified AFAIK would (atleast directly) have > effect on > > > X. Any ideas? > > > > Yes, two of them: > > > > 1. It may be that radeon driver gives window buffer address directly to > > the GPU and since this page(s) are mapped in dom0 from another domain, > it > > may cause some weird interactions, including VT-d preventing the > > operation. You may try to disable compositing. > > > > 2. In both cases SEGV happens already in error handling > > (SendErrorToClient+0x2df on the stack). It may be helpful to find out > > what the error is. Hmm, remove_fs_handlers also looks like some cleanup > > function, so the actual problem is probably a little earlier. Any more > > info in the log? > > It is something else: lack of #define XC_WANT_COMPAT_MAP_FOREIGN_API in > shmoverride.c >
Nice! I can confirm that this fixed the Xorg crash issue (also can open normally VM windows, since shmoverride is now operating). > > And BTW it is not needed to include xenctrl_compat.h manually. By not > doing this, the code is compatible with both new and old Xen. See > xen-4.7 branch in marmarek/qubes-core-vchan-xen. > > As for vmm-xen repository - could you rebase it on top of xen-4.6 to > cleanup history? Otherwise I would need to cherry-pick individual > commits, which will remove signatures on them. > > Done. Updated also XSA182 patch formatting and removed XSA154 patch (already on Xen 4.7). > - -- > 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 > > iQEcBAEBCAAGBQJXp/pZAAoJENuP0xzK19csfKIH/00ZxX4qaKjH30rcpo22xwz5 > zW07ZoGbJXbq7IGvBOhYoxPoZgmxgbUNBGF5/bFziqSSHV5bCA094twZXGAm9zpv > Z7AHP1RC9zGNoE9E8A/QdtTjqXTHpxxGGLwz1NSP6mHrvcc7DzVnWk3p0iTN4vcE > mTOHM650grwQ2KplK8BEUE/TO8MW5VCckwf399kNBQ9iU65063r9ypq5dk5Eya+W > KE8iS/b0Zxl2jfhpgtKXOpvD7PFAtJYYUugAaymudcPa/oKvnjW+nmyOPSi6NLO2 > wi5UHCkQK0Meu46o3RYNbIewFf4h/AEY2WZ743EDprpHWqBVs7Jvp7VwXiG945E= > =xjnh > -----END PGP SIGNATURE----- > Best regards, Marcus -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/90c2ae03-9f7f-433d-89f3-0498a1bf9c57%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
