[qubes-users] Re: Too small num_mfn in MSG_MFNDUMP
On Tuesday, September 25, 2018 at 2:12:29 PM UTC-5, tyler.e@raytheon.com wrote: > I am getting an error when the gui-daemon in dom0 receives a MSG_MFNDUMP > message from the domU gui-agent. Somehow the number of frame numbers > reported from the domU doesn't match up with the size of the window. I've > posted the log from the dom0 guid at the end of this message. > > Initially, it looks like a window for gsd-xsettings is created just fine and > the dom0 receives the messages, no problem. For testing, I then started an > instance of xclock in domU and it runs into trouble when doing the mfndump. > Looking at the log messages, I can't tell if the size of the window is > supposed to be 164x164 or 1280x1024. Xclock is usually has a small > application window, but using either size, something erroneous is going on. > There is some issue when it comes to computing num_mfn. num_mfn is computed > with the following code snippet: > > pixels = pixmap->devPrivate.ptr; > > > pixels_end = > > > pixels + > > > pixmap->drawable.width * pixmap->drawable.height * > > > pixmap->drawable.bitsPerPixel / 8; > > > off = ((long) pixels) & (4096-1); > > > pixels -= off; > > > num_mfn = ((long) pixels_end - (long) pixels + 4095) >> 12; > > > shmcmd.width = pixmap->drawable.width; > > > shmcmd.height = pixmap->drawable.height; > > > num_mfn is computed by using the starting address, adding the amount of data > the window occupies to find the ending address, and subtracting the two. > There are a few extra things to align the address to 4K pages. In the error > log below, the width and height that are part of the MSG_MFNDUMP are > 1280x1024. Yet, somehow num_mfn is only 0x141. According to the above code > and assuming 3 bytes per pixel, it should be something close to > (1280x1024x3)/4096 = 0x3c0. Even if the size was 164x164, num_mfn should be > close to (164x164x3)/4096 = 0x19. Somehow the dom0 receives a width and > height of 1280x1024 yet it also receives from the domU that num_mfn = 0x141. > > Looking at the code for computing num_mfn, the only thing I can think of that > might affect num_mfn being too small is truncation error from doing pointer > arithmetic using "long." There could be 64 bit addresses but only 32 bit > longs and some higher order bits are being lost when computing num_mfn. > Maybe something like "ptrdiff_t" or "uint64_t" could have been used. That > being said, it shouldn't matter because everything was compiled for 64 bit > machines, right? > > Any help figuring out what's going on here would be greatly appreciated! > > dom0 guid log: > > Created 0x23(0x61) parent 0x0(0x19b) ovr=1 x/y -1/-1 w/h 1/1 > set title for window 0x23 > set title for window 0x23 > Created 0x24(0x81) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10 > set WM_NORMAL_HINTS for window 0x24 to min=0/0, max=0/0, base=0/0, > inc=0/0 (flags 0x0) > set title for window 0x24 > set class hint for window 0x24 to (linux_domu:Gsd-xsettings, > linux_domu:gsd-xsettings) > XDestroyWindow 0x24 > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot
[qubes-users] Too small num_mfn in MSG_MFNDUMP
I am getting an error when the gui-daemon in dom0 receives a MSG_MFNDUMP message from the domU gui-agent. Somehow the number of frame numbers reported from the domU doesn't match up with the size of the window. I've posted the log from the dom0 guid at the end of this message. Initially, it looks like a window for gsd-xsettings is created just fine and the dom0 receives the messages, no problem. For testing, I then started an instance of xclock in domU and it runs into trouble when doing the mfndump. Looking at the log messages, I can't tell if the size of the window is supposed to be 164x164 or 1280x1024. Xclock is usually has a small application window, but using either size, something erroneous is going on. There is some issue when it comes to computing num_mfn. num_mfn is computed with the following code snippet: pixels = pixmap->devPrivate.ptr; pixels_end = pixels + pixmap->drawable.width * pixmap->drawable.height * pixmap->drawable.bitsPerPixel / 8; off = ((long) pixels) & (4096-1); pixels -= off; num_mfn = ((long) pixels_end - (long) pixels + 4095) >> 12; shmcmd.width = pixmap->drawable.width; shmcmd.height = pixmap->drawable.height; num_mfn is computed by using the starting address, adding the amount of data the window occupies to find the ending address, and subtracting the two. There are a few extra things to align the address to 4K pages. In the error log below, the width and height that are part of the MSG_MFNDUMP are 1280x1024. Yet, somehow num_mfn is only 0x141. According to the above code and assuming 3 bytes per pixel, it should be something close to (1280x1024x3)/4096 = 0x3c0. Even if the size was 164x164, num_mfn should be close to (164x164x3)/4096 = 0x19. Somehow the dom0 receives a width and height of 1280x1024 yet it also receives from the domU that num_mfn = 0x141. Looking at the code for computing num_mfn, the only thing I can think of that might affect num_mfn being too small is truncation error from doing pointer arithmetic using "long." There could be 64 bit addresses but only 32 bit longs and some higher order bits are being lost when computing num_mfn. Maybe something like "ptrdiff_t" or "uint64_t" could have been used. That being said, it shouldn't matter because everything was compiled for 64 bit machines, right? Any help figuring out what's going on here would be greatly appreciated! dom0 guid log: Created 0x23(0x61) parent 0x0(0x19b) ovr=1 x/y -1/-1 w/h 1/1 set title for window 0x23 set title for window 0x23 Created 0x24(0x81) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10 set WM_NORMAL_HINTS for window 0x24 to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x0) set title for window 0x24 set class hint for window 0x24 to (linux_domu:Gsd-xsettings, linux_domu:gsd-xsettings) XDestroyWindow 0x24 cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata cannot lookup 0x24 in wid2windowdata Created 0x25(0xa1) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10 set WM_NORMAL_HINTS for window 0x25 to min=0/0, max=0/0,
