On 16.08.2023 01:03, Stefano Stabellini wrote: > On Tue, 15 Aug 2023, Andrew Cooper wrote: >> The arch_get_xen_caps() infrastructure is horribly inefficient for something >> that is constant after features have been resolved on boot. >> >> Every instance used snprintf() to format constants into a string (which gets >> shorter when %d gets resolved!), and which get double buffered on the stack. >> >> Switch to using string literals with the "3.0" inserted - these numbers >> haven't changed in 18 years (The Xen 3.0 release was Dec 5th 2005). >> >> Use initcalls to format the data into xen_cap_info, which is deliberately not >> of type xen_capabilities_info_t because a 1k array is a silly overhead for >> storing a maximum of 77 chars (the x86 version) and isn't liable to need any >> more space in the forseeable future. >> >> This speeds up the the XENVER_capabilities hypercall, but the purpose of the >> change is to allow us to introduce a better XENVER_* API that doesn't force >> the use of a 1k buffer on the stack. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > > Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
Acked-by: Jan Beulich <jbeul...@suse.com> albeit I still think your original concern regarding ... >> @@ -537,7 +538,7 @@ long do_xen_version(int cmd, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> >> memset(info, 0, sizeof(info)); >> if ( !deny ) >> - arch_get_xen_caps(&info); >> + safe_strcpy(info, xen_cap_info); >> >> if ( copy_to_guest(arg, info, ARRAY_SIZE(info)) ) >> return -EFAULT; ... the unhelpful use of a stack variable here could do with addressing. But of course that can equally be done in a subsequent patch. Jan
