On 21/05/15 12:48, Jan Beulich wrote: >>>> On 21.05.15 at 13:08, <andrew.coop...@citrix.com> wrote: >> On 21/05/15 11:15, Jan Beulich wrote: >>> This is needed as stacks are going to become non-executable. Use >>> separate stub pages (shared among suitable CPUs on the same node) >>> instead. >>> >>> Stub areas (currently 128 bytes each) are being split into two parts - >>> a fixed usage one (the syscall ones) and dynamically usable space, >>> which will be used by subsequent changes to hold dynamically generated >>> code during instruction eumlation. >>> >>> While sharing physical pages among certain CPUs on the same node, for >>> now the virtual mappings get established in distinct pages for each >>> CPU. This isn't a strict requirement, but simplifies VA space >>> management for this initial implementation: Sharing VA space would >>> require additional tracking of which areas are currently in use. If >>> the VA and/or TLB overhead turned out to be a problem, such extra code >>> could easily be added. >>> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> >> >> It might be wise to have a BUILD_BUG_ON() which confirms that >> STUBS_PER_PAGE is a power of two, which is a requirement given the way >> it is used. > Good idea. Along with that one I'm also adding > > BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX_INST_LEN + 1); > > to patch 2 and > > BUILD_BUG_ON(STUB_BUF_SIZE / 2 < 16); > > to patch 3, in the hope that this won't invalidate your R-b.
Both fine by me ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
