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

Re: [PATCH 1/4] x86/guest: move allocation of Xen upcall vector to init code


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 20 Nov 2025 11:01:36 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=k8U+VBh4pERobnJvTuByqG4B4pFfkMK052GaaIaUlOo=; b=c8fmNZwXfS8dx9gkYxT4/vNWNjzErxToIV8edumG9VzNZZYRsqqORHz1LS8/6vQPm5bhg7RgpTK0CULeIu26Em/o3C70WohLsztaTaZuDL6569xMoZ9KOq7Vc7Uw1qXSAJAaaIdTusbBjC9T0gGV5J8EMqTRbJJcoRG4CaA0TKQqWltQpdyjSmuO16Z3prMfwn1i44yfia7jgbcOHmFv/XVRgCPcAMpbzB1XCVoOMXzKc7ChveGH2+8k17Nk0Xj5vWiiUG1QDikY2O9gYuSt1E1feQwLW6OXhwJCz9Lr4O60eZq8jIpnBs8ixeMVA5z+GULGwJYzbIqPorCtV5EdmA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l9CEM/azyOw+qAlg8dQ6chtUhrp8UL5l3AnbKAWCkk28PnGNWlQPtIJfVbS4SlBy3TEfVy/wIIL62I02ddNufOzs/S+opdWSf+V5kgIDSSBCu3nCA8OHV6XGTtz0BNZClmNzhjGCw5q3LwgEvaOoPieKeHNyn5kfu53Y0SQhpjzLSCkB1O6lajWMQJyVs97ahYnq1gzRpCYpQzHxjWc4yBE+i+Fo8XuA+eG3MIUYLeWtA+osxsEnu6ORZMmHTjf35JsEPZaht3bJ7HEZQYnhT+/YMET5RHYjLommG4NEwqf6BVyGEr3b/xRY2eXKIK3g1+ooUx5HXvI21Fw+z0esTw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 20 Nov 2025 11:02:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/11/2025 10:50 am, Jan Beulich wrote:
> There's no need to do this every time init_evtchn() is called. Just do it
> once when setting up CPU0. Drop the assertion as well, as
> alloc_hipriority_vector() (called by alloc_direct_apic_vector()) uses more
> restrictive BUG_ON() anyway. Then evtchn_upcall_vector can also validly
> become ro-after-init, just that it needs to move out of init_evtchn().
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> --- a/xen/arch/x86/guest/xen/xen.c
> +++ b/xen/arch/x86/guest/xen/xen.c
> @@ -233,16 +233,12 @@ static void cf_check xen_evtchn_upcall(v
>      ack_APIC_irq();
>  }
>  
> +static uint8_t __ro_after_init evtchn_upcall_vector;
> +
>  static int init_evtchn(void)
>  {
> -    static uint8_t evtchn_upcall_vector;
>      int rc;
>  
> -    if ( !evtchn_upcall_vector )
> -        alloc_direct_apic_vector(&evtchn_upcall_vector, xen_evtchn_upcall);
> -
> -    ASSERT(evtchn_upcall_vector);
> -
>      rc = xen_hypercall_set_evtchn_upcall_vector(this_cpu(vcpu_id),
>                                                  evtchn_upcall_vector);
>      if ( rc )
> @@ -293,6 +289,8 @@ static void __init cf_check setup(void)
>                 XEN_LEGACY_MAX_VCPUS);
>      }
>  
> +    alloc_direct_apic_vector(&evtchn_upcall_vector, xen_evtchn_upcall);
> +
>      BUG_ON(init_evtchn());
>  }
>  
>

This patch is fine, but it would be nicer to split init_evtchn() into
bsp_init_evtchn() and percpu_init_evtchn().

Just out of context in init_evtchn(), there's a check for CPU0 that also
ought to move into bsp_init_evtchn() (and therefore into __init), at
which point the percpu simplifies to a single hypercall, and we keep
subsystem specifics out of setup().

~Andrew



 


Rackspace

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