From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5A023CEBF8C for ; Fri, 27 Sep 2024 09:29:22 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.806156.1217481 (Exim 4.92) (envelope-from ) id 1su7Hj-0000Bj-Vi; Fri, 27 Sep 2024 09:29:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 806156.1217481; Fri, 27 Sep 2024 09:29:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1su7Hj-0000Bc-T0; Fri, 27 Sep 2024 09:29:11 +0000 Received: by outflank-mailman (input) for mailman id 806156; Fri, 27 Sep 2024 09:29:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1su7Hj-0000BW-B7 for xen-devel@lists.xenproject.org; Fri, 27 Sep 2024 09:29:11 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f37eafca-7cb2-11ef-a0ba-8be0dac302b0; Fri, 27 Sep 2024 11:29:10 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a8a897bd4f1so258628566b.3 for ; Fri, 27 Sep 2024 02:29:10 -0700 (PDT) Received: from localhost ([213.195.124.163]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c27c5a7dsm110058866b.62.2024.09.27.02.29.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Sep 2024 02:29:09 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f37eafca-7cb2-11ef-a0ba-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1727429350; x=1728034150; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7hrPMKJO7moi4CffiFfmTeaKikPGisFREqDzJg4sfAs=; b=q3SXUXhURukJa8QMN9EOYBsrqrda+Mogh2J+sH+tpDNI/hAb5hYR8YABfyKNN54YP1 QgBucTjxr7SZAKkV81Nh6dzcQO34PLH10bqM5+XjhMDvWuPDY/3jU3OCd4SQ3e4qggpi 4Hf0V58e7xoic13n85DA05QIcwG6cQXMAsFFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727429350; x=1728034150; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7hrPMKJO7moi4CffiFfmTeaKikPGisFREqDzJg4sfAs=; b=IfJ/kPTOS3pzYlJtZswPaVcdqwTd45JiIZUBv4FZjygceu+j6/Z5hB6wTzgfUKLzoq KFPRVg76TZj0okKehw0AXL1PCxZ/+KlvsWE3MKVOmlcP6mTBWWkoiMxnW+EY2qgiX87s B44/moxEjn//NEoBrsVSOHcHAnoJunK+BjbmfBD9q4Yyoqqn9fP9kENCdYcJDCIXjLyW eDBHsjThKkYGRks0CX1lux4NvR7dFEl7Qgoz8JdQ6wL+fwkY153l3ZshtaHAxJOuQzhQ W0JXTmLqoYX/nPGC4w9GcE7stJLsu7HTfqY3LEfUJVeEKMljL3t+3bjzMg1VbL9v5ZmR k9MA== X-Gm-Message-State: AOJu0YzIe8MiTzw1QNUNwggx1w0/fHZjzA+ShYXfnq03Vold+OjjQXBL MNrjqgTxolfph4qCtohzIIbf0ce+9iQs5I/y6yxOE185BuoqXU/b4WLSQ+2p2vTojZCxu+d0IaZ G X-Google-Smtp-Source: AGHT+IGZd+rscmvWMp2DqEYiGy+Jzf4d/OdRyKbVLvW4wD6EgIKEkj3K4/1BFgc0bo44Qc0sg6PRhA== X-Received: by 2002:a17:907:6d23:b0:a88:b90a:ff30 with SMTP id a640c23a62f3a-a93c4a62739mr242274466b.50.1727429349846; Fri, 27 Sep 2024 02:29:09 -0700 (PDT) Date: Fri, 27 Sep 2024 11:29:08 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH 15/22] x86/idle: allow using a per-pCPU L4 Message-ID: References: <20240726152206.28411-1-roger.pau@citrix.com> <20240726152206.28411-16-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Wed, Aug 21, 2024 at 05:42:26PM +0100, Alejandro Vallejo wrote: > On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote: > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > index 9cfcf0dc63f3..b62c4311da6c 100644 > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -555,6 +555,7 @@ void arch_vcpu_regs_init(struct vcpu *v) > > int arch_vcpu_create(struct vcpu *v) > > { > > struct domain *d = v->domain; > > + root_pgentry_t *pgt = NULL; > > int rc; > > > > v->arch.flags = TF_kernel_mode; > > @@ -589,7 +590,23 @@ int arch_vcpu_create(struct vcpu *v) > > else > > { > > /* Idle domain */ > > - v->arch.cr3 = __pa(idle_pg_table); > > + if ( (opt_asi_pv || opt_asi_hvm) && v->vcpu_id ) > > + { > > + pgt = alloc_xenheap_page(); > > + > > + /* > > + * For the idle vCPU 0 (the BSP idle vCPU) use idle_pg_table > > + * directly, there's no need to create yet another copy. > > + */ > > Shouldn't this comment be in the else branch instead? Or reworded to refer to > non-0 vCPUs. Sure, moved to the else branch. > > + rc = -ENOMEM; > > While it's true rc is overriden later, I feel uneasy leaving it with -ENOMEM > after the check. Could we have it immediately before "goto fail"? I have to admit I found this coding style weird at first, but it's used all over Xen. I don't mind setting rc ahead of the goto, AFAICT the only benefit of the current style is that we can avoid the braces around the if code block for it being a single statement. > > + if ( !pgt ) > > + goto fail; > > + > > + copy_page(pgt, idle_pg_table); > > + v->arch.cr3 = __pa(pgt); > > + } > > + else > > + v->arch.cr3 = __pa(idle_pg_table); > > rc = 0; > > v->arch.msrs = ZERO_BLOCK_PTR; /* Catch stray misuses */ > > } > > @@ -611,6 +628,7 @@ int arch_vcpu_create(struct vcpu *v) > > vcpu_destroy_fpu(v); > > xfree(v->arch.msrs); > > v->arch.msrs = NULL; > > + free_xenheap_page(pgt); > > > > return rc; > > } > > I guess the idle domain has a forever lifetime and its vCPUs are kept around > forever too, right?; otherwise we'd need extra logic in the the vcpu_destroy() > to free the page table copies should they exist too. Indeed, vcpus are only destroyed when destroying domains, and system domains are never destroyed. Thanks, Roger.