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

Re: [PATCH 2/2] x86: Remove stubs from asm/pv/domain.h


  • To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
  • Date: Wed, 12 Nov 2025 17:56:14 +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=s1AXOjqK7Zh/8g0QjNTicma1iqBPbyRrbdmUBx8soSQ=; b=ypZefSO5kM4s3azrt3h2VWUg7KF0YBlW4gfUVeMAI2zXIbL2sCGH2xVmu5BORAwAKAU9xfTxVTJXKTUKqvTzIzWFk1C4qBorGAMNh0XE/KHoKkJ4tVb0kvLCxk2R4JA6iaLivmFxVkeNFh5m1317pDGvSVDLZIhin0mh3AZItsfCCPPiAjV0+ElxdwpB3c8/TbFnV1HRALNyhV1rEn7DjgQK6tOicoDHkjTiAbY5LRdDMnqYO3VsiZ2UMbg5rIbfYLYmihwQtHe6DYcXu+b1mK+oABrHbTmR42C1NfLBsV6ukWeJWYok8K2VhiazOte6bMVV3WcMeo+DCBk01fecyg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TXjxJD+vhfLOxH1KoEtOukKNtIvqXkGYD9C3boBbNvWTucZv5G+wAnbyQWB3FDK4sdA/Du187eeHxhIrkzxk9yCpPTpXsjRmuJ5XujeZDWIEXkews5atAIsiKjfcWqdpSCIjtjjDwJn9s78ag3xYkwse6UB5WiLdOZ6SveIRtWgB6ovS5OzpUDTvIEBz9pmsuxqByHec4YkMkupjE0IDuOY2f0J1STVu8OCyEuYkLVO1Z5LZTTNEvdRzdp5X9jRovE9HYAeGDmZ5IFi44Gxs2yM5TlwioxEX62hmUfglOnZ4S6pL/ktMLvyOjSz60RE/EEUJDTqjRz3rFGquLDHjhQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <Jason.Andryuk@xxxxxxx>
  • Delivery-date: Wed, 12 Nov 2025 15:56:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>



On 12.11.25 17:22, Alejandro Vallejo wrote:
They are unnecessary. The only two cases with link-time failures are
fallback else branches that can just as well be adjusted with explicit
IS_ENABLED(CONFIG_PV). HVM has no equivalent stubs and there's no reason
to keep the asymmetry.

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
---
I'd rather remove the "rc = -EOPNOTSUPP" branch altogether, or replace
it with ASSERT_UNREACHABLE(), but I kept it here to preserve prior behaviour.

Thoughts?

---
  xen/arch/x86/domain.c                | 10 ++++++----
  xen/arch/x86/include/asm/pv/domain.h | 25 -------------------------
  2 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 19fd86ce88..0977d9323d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -571,15 +571,17 @@ int arch_vcpu_create(struct vcpu *v)
if ( is_hvm_domain(d) )
          rc = hvm_vcpu_initialise(v);
-    else if ( !is_idle_domain(d) )
-        rc = pv_vcpu_initialise(v);
-    else
+    else if ( is_idle_domain(d) )
      {

The is_idle_domain() wants to go first here, i think.
[1] https://patchwork.kernel.org/comment/26646246/

          /* Idle domain */
          v->arch.cr3 = __pa(idle_pg_table);
          rc = 0;
          v->arch.msrs = ZERO_BLOCK_PTR; /* Catch stray misuses */
      }
+    else if ( IS_ENABLED(CONFIG_PV) )
+        rc = pv_vcpu_initialise(v);
+    else
+        rc = -EOPNOTSUPP;
if ( rc )
          goto fail;

Actually, if you are here and have time and inspiration :)
- if ( is_idle_domain(d) ) staff can be consolidated at the
  beginning of arch_vcpu_create() which will make it much more readable and 
simple.
- mapcache_vcpu_init() is PV only (->pv_vcpu_initialise()?)

@@ -614,7 +616,7 @@ void arch_vcpu_destroy(struct vcpu *v)
if ( is_hvm_vcpu(v) )
          hvm_vcpu_destroy(v);
-    else
+    else if ( IS_ENABLED(CONFIG_PV) )
          pv_vcpu_destroy(v);
  }


--
Best regards,
-grygorii




 


Rackspace

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