>>> On 21.05.15 at 13:48, <jbeul...@suse.com> 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.
Sadly this can't be a BUILD_BUG_ON(), as STUBS_PER_PAGE isn't a compile time constant (due to the use of max()). I made it an ASSERT() for the time being. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
