On Tue, May 07, 2019 at 02:10:20AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 16:50, <marma...@invisiblethingslab.com> wrote: > > Found while debugging framebuffer located above 4GB. In that case 32bit > > variable for it overflows and framebuffer initialization zeroed > > unrelated memory. Specifically, it hit mbi->mods_count, so later on > > bitmap_fill(module_map, mbi->mods_count) in __start_xen() crashed. > > The origin of your problem being a truncation one, it seems pretty > clear to me that if we want to be able to gracefully handle that, > then we need to stop using plain int in all the involved functions. > I'm curious though which bitmap_fill() it was that you saw misbehave: > There's no such call at all in xen/drivers/video/, and I'm also having > a hard time seeing how the address (rather than the size) of the > frame buffer could be involved here.
Truncated framebuffer address (0x0) caused memset() in vesa_init() to zero (among other things) mbi->mods_count. This triggered the crash as described above. Obviously, bitmap_fill() crash was just a fallout here, not the root cause. -- 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?
signature.asc
Description: PGP signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
