[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN][PATCH v3] xen/x86: guest_access: optimize raw_x_guest() for PV and HVM combinations


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
  • Date: Wed, 12 Nov 2025 13:27:51 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q1I9TJrjgMudyBKRZmrKvMnKVLHf4X1aEgWQ4H56dCI=; b=w3iCs4Cz1TLWCMryLhUBXRjzV8DYnLGVHPOGKIDyUSktbLHBaUyPkSF1O5OXs2iEeBMHNnlX28B0p/Vqp8SIGYR75GIbYnyASjM99jmnmr3mV1imYNaN1jaK1ZtBtnzxPap/jt3gqO8agrkOMVwMIEEotdnvXWta1M9SqHclkErb0nEMGpxLGBJV/wL48kpBX3cexQMTyGNAnubBAQKsdiuiJjraOudQz531gGwY3DrLwuz469366bKyO75T8+DqJmt7KZvGqOJzf1ECxd+KoXjvrLYzrN1AjLjSQE+thgODIxW5OXBL2l+5FEbYIwTkROv6XP6UH9tSTnZnf1ks2A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QKWGvRsKvdJVdAX2IcizvNgwhBexT03cAQ5G8wxpTp0N14Him3VxXv/YiQI+x2pg5QpS3ApRxw3i6LlKvWLOinKPrWTp+55CbnXDg65Z1jFPkFQa8vc7/Q+NGf3jZh4rbbvn8AImXVWAqm3X7Vq39PSgjcukry2cqZs+dMBlMibPzdvj3CPQSbX706OUaQTDYkGv3jWxLok01Cj2Ego5m3y0qLhQ0qnoHrzM6uWgbsF9a7njPW0pwKmCS6cfq0tKCZgxSLpNLzFUR1W+f04t9UNSRYTDQAB2B9fYc+IHcmnfaSP9Nz7/qngLziO4akyBlan4tPtX4cZAU7Wx8nUuTA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Lira, Victor M" <victlira@xxxxxxx>
  • Delivery-date: Wed, 12 Nov 2025 11:28:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>



On 12.11.25 08:38, Jan Beulich wrote:
On 11.11.2025 18:52, Grygorii Strashko wrote:
On 10.11.25 09:11, Jan Beulich wrote:
On 07.11.2025 19:17, Grygorii Strashko wrote:
--- a/xen/arch/x86/include/asm/guest_access.h
+++ b/xen/arch/x86/include/asm/guest_access.h
@@ -13,26 +13,64 @@
   #include <asm/hvm/guest_access.h>
     /* Raw access functions: no type checking. */
-#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))
-#define raw_copy_from_guest(dst, src, len)      \
-    (is_hvm_vcpu(current) ?                     \
-     copy_from_user_hvm((dst), (src), (len)) :  \
-     copy_from_guest_pv(dst, src, len))
-#define raw_clear_guest(dst,  len)              \
-    (is_hvm_vcpu(current) ?                     \
-     clear_user_hvm((dst), (len)) :             \
-     clear_guest_pv(dst, len))
-#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))
-#define __raw_copy_from_guest(dst, src, len)    \
-    (is_hvm_vcpu(current) ?                     \
-     copy_from_user_hvm((dst), (src), (len)) :  \
-     __copy_from_guest_pv(dst, src, len))
+static inline bool raw_use_hvm_access(const struct vcpu *v)
+{
+    return IS_ENABLED(CONFIG_HVM) && (!IS_ENABLED(CONFIG_PV) || 
is_hvm_vcpu(v));
+}

Without a full audit (likely tedious and error prone) this still is a
behavioral change for some (likely unintended) use against a system domain
(likely the idle one): With HVM=y PV=n we'd suddenly use the HVM accessor
there. IOW imo the "system domains are implicitly PV" aspect wants
retaining, even if only "just in case". It's okay not to invoke the PV
accessor (but return "len" instead), but it's not okay to invoke the HVM
one.

This patch is subset of "constify is_hvm_domain() for PV=n case" attempts.

It was made under assumption that:
"System domains do not have Guests running, so can't initiate hypecalls and
  can not be users of copy_to/from_user() routines. There are no Guest and no user 
memory".
[IDLE, COW, IO, XEN]

If above assumption is correct - this patch was assumed safe.

if not - it all make no sense, probably.

I wouldn't go as far as saying that. It can be arranged to avid the corner
case I mentioned, I think.

do you mean adding "&& !is_system_domain(v->domain)" in raw_use_hvm_access()?

Hm, I see that vcpu(s) are not even created for system domains in 
domain_create().
So seems !is_system_domain(v->domain) == true always here.

Am I missing smth?
Or you meant smth. else?


--
Best regards,
-grygorii




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.