On 2025-11-07 13:17, Grygorii Strashko wrote:
From: Grygorii Strashko <[email protected]>Xen uses below pattern for raw_x_guest() functions: define raw_copy_to_guest(dst, src, len) \ (is_hvm_vcpu(current) ? \ copy_to_user_hvm((dst), (src), (len)) : \ copy_to_guest_pv(dst, src, len)) This pattern works depending on CONFIG_PV/CONFIG_HVM as: - PV=y and HVM=y Proper guest access function is selected depending on domain type. - PV=y and HVM=n Only PV domains are possible. is_hvm_domain/vcpu() will constify to "false" and compiler will optimize code and skip HVM specific part. - PV=n and HVM=y Only HVM domains are possible. is_hvm_domain/vcpu() will not be constified. No PV specific code will be optimized by compiler. - PV=n and HVM=n No guests should possible. The code will still follow PV path. Rework raw_x_guest() code to use static inline functions which account for above PV/HVM possible configurations with main intention to optimize code for (PV=n and HVM=y) case. For the case (PV=n and HVM=n) return "len" value indicating a failure (no guests should be possible in this case, which means no access to guest memory should ever happen). Finally build arch/x86/usercopy.c only for PV=y. The measured (bloat-o-meter) improvement for (PV=n and HVM=y) case is: add/remove: 2/9 grow/shrink: 2/90 up/down: 1678/-32560 (-30882) Total: Before=1937092, After=1906210, chg -1.59% [[email protected]: Suggested to use static inline functions vs macro combinations] Suggested-by: Teddy Astie <[email protected]> Signed-off-by: Grygorii Strashko <[email protected]>
Reviewed-by: Jason Andryuk <[email protected]> Thanks, Jason
