On 08.01.2020 20:41, Andrew Cooper wrote: > On 08/01/2020 11:23, Jan Beulich wrote: >>>> This would then also ease shrinking the build >>>> time mappings further, e.g. to the low 1Mb (instead of touching >>>> several of the places you touch now, it would again mainly be an >>>> adjustment to BOOTSTRAP_MAP_BASE, alongside the assembly file >>>> changes needed). >>> ... as you correctly identify here, it is a property of the prebuilt >>> tables (in l?_identmap[]), not a property of where we chose to put the >>> dynamic boot mappings (in the l?_bootmap[]). Another change (blocked >>> behind the above bug) moves BOOTSTRAP_MAP_BASE to be 1G to reduce the >>> chance of an offset from a NULL pointer hitting a present mapping. >> Right, BOOTSTRAP_MAP_BASE was (ab)used for a 2nd purpose. But this >> would better be dealt with by introducing a new manifest constant >> (e.g. PREBUILT_MAP_LIMIT) instead of open-coding 2Mb everywhere. > > I'm hoping to get rid of even this, (although it is complicated by > CONFIG_VIDEO's blind use of the legacy VGA range). > >> Plus there's (aiui) a PREBUILT_MAP_LIMIT <= BOOTSTRAP_MAP_BASE >> requirement, which would better be verified (e.g. by a BUILD_BUG_ON()) >> then. > > Is there? I don't see a real connection between the two, even in this > patch.
Perhaps not a "real" one (in the sense that I think you mean), but at the very least when PREBUILT_MAP_LIMIT > BOOTSTRAP_MAP_BASE adding a first bootstrap mapping would _require_ a TLB flush, whereas things would be fine without otherwise (albeit this going through map_pages_to_xen() means appropriate flushing will be done anyway). Anything else depends on the potentially overlapping range actually being used for something (which your series proves it's not). Anyway, as said before, considering your subsequent changes, there's no real need to add any further checking here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
