All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: scott.davis@starlab.io, christopher.clark@starlab.io,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Dario Faggioli" <dfaggioli@suse.com>,
	xen-devel@lists.xenproject.org, "Wei Liu" <wl@xen.org>
Subject: Re: [PATCH v1 14/18] x86: generalize vcpu for domain building
Date: Wed, 27 Jul 2022 14:46:02 +0200	[thread overview]
Message-ID: <481ea371-df3f-287f-5952-262433342f28@suse.com> (raw)
In-Reply-To: <20220706210454.30096-15-dpsmith@apertussolutions.com>

On 06.07.2022 23:04, Daniel P. Smith wrote:
> Here, the vcpu initialization code for dom0 creation is generalized for use for
> other domains.

Yet with "other domains" still only ones created during boot, aiui.
Imo such details want spelling out.

The title also is too generic / imprecise.

> --- a/xen/arch/x86/domain_builder.c
> +++ b/xen/arch/x86/domain_builder.c
> @@ -28,6 +28,18 @@ static unsigned int __init dom_max_vcpus(struct boot_domain *bd)
>          return bd->ncpus;
>  }
>  
> +struct vcpu *__init alloc_dom_vcpu0(struct boot_domain *bd)

domain_alloc_vcpu0()?

> +{
> +    if ( bd->functions & BUILD_FUNCTION_INITIAL_DOM )
> +        return alloc_dom0_vcpu0(bd->domain);
> +
> +    bd->domain->node_affinity = node_online_map;
> +    bd->domain->auto_node_affinity = true;

I can spot neither consumers of nor code being replaced by this.

> +    return vcpu_create(bd->domain, 0);
> +}
> +
> +
>  void __init arch_create_dom(

No double blank lines please.

> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -14,6 +14,8 @@
>   */
>  
>  #ifndef COMPAT
> +#include <xen/bootdomain.h>
> +#include <xen/domain_builder.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/param.h>
> @@ -3399,13 +3401,13 @@ void wait(void)
>  }
>  
>  #ifdef CONFIG_X86
> -void __init sched_setup_dom0_vcpus(struct domain *d)
> +void __init sched_setup_dom_vcpus(struct boot_domain *bd)

Perhaps simply drop the original _dom0 infix?

>  {
>      unsigned int i;
>      struct sched_unit *unit;
>  
> -    for ( i = 1; i < d->max_vcpus; i++ )
> -        vcpu_create(d, i);
> +    for ( i = 1; i < bd->domain->max_vcpus; i++ )
> +        vcpu_create(bd->domain, i);

Seeing the further uses below, perhaps better introduce a local variable
"d", like you do elsewhere?

> @@ -3413,19 +3415,24 @@ void __init sched_setup_dom0_vcpus(struct domain *d)
>       * onlining them. This avoids pinning a vcpu to a not yet online cpu here.
>       */
>      if ( pv_shim )
> -        sched_set_affinity(d->vcpu[0]->sched_unit,
> +        sched_set_affinity(bd->domain->vcpu[0]->sched_unit,
>                             cpumask_of(0), cpumask_of(0));
>      else
>      {
> -        for_each_sched_unit ( d, unit )
> +        for_each_sched_unit ( bd->domain, unit )
>          {
> -            if ( !opt_dom0_vcpus_pin && !dom0_affinity_relaxed )
> -                sched_set_affinity(unit, &dom0_cpus, NULL);
> -            sched_set_affinity(unit, NULL, &dom0_cpus);
> +            if ( builder_is_initdom(bd) )
> +            {
> +                if ( !opt_dom0_vcpus_pin && !dom0_affinity_relaxed )
> +                    sched_set_affinity(unit, &dom0_cpus, NULL);
> +                sched_set_affinity(unit, NULL, &dom0_cpus);
> +            }
> +            else
> +                sched_set_affinity(unit, NULL, cpupool_valid_cpus(cpupool0));

Hard-coded cpupool0?

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -2,6 +2,7 @@
>  #ifndef __SCHED_H__
>  #define __SCHED_H__
>  
> +#include <xen/bootdomain.h>

Please don't - this header has already too many dependencies. All you really
need ...

> @@ -1003,7 +1004,7 @@ static inline bool sched_has_urgent_vcpu(void)
>  }
>  
>  void vcpu_set_periodic_timer(struct vcpu *v, s_time_t value);
> -void sched_setup_dom0_vcpus(struct domain *d);
> +void sched_setup_dom_vcpus(struct boot_domain *d);

... for this is a forward declaration of struct boot_domain.

Jan


  reply	other threads:[~2022-07-27 12:46 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 21:04 [PATCH v1 00/18] Hyperlaunch Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 01/18] kconfig: allow configuration of maximum modules Daniel P. Smith
2022-07-07  1:44   ` Henry Wang
2022-07-15 19:16   ` Julien Grall
2022-07-19 16:36     ` Daniel P. Smith
2022-07-26 18:07       ` Julien Grall
2022-07-27  6:12         ` Jan Beulich
2022-07-19  9:32   ` Jan Beulich
2022-07-19 17:02     ` Daniel P. Smith
2022-07-20  7:27       ` Jan Beulich
2022-07-22 15:00         ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 02/18] introduction of generalized boot info Daniel P. Smith
2022-07-15 19:25   ` Julien Grall
2022-07-20 18:32     ` Daniel P. Smith
2022-07-19 13:11   ` Jan Beulich
2022-07-21 14:28     ` Daniel P. Smith
2022-07-21 16:00       ` Jan Beulich
2022-07-21 16:00       ` Jan Beulich
2022-07-22 16:01         ` Daniel P. Smith
2022-07-25  7:05           ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 03/18] x86: adopt new boot info structures Daniel P. Smith
2022-07-19 13:19   ` Jan Beulich
2022-07-22 12:34     ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 04/18] x86: refactor entrypoints to new boot info Daniel P. Smith
2022-07-18 13:58   ` Smith, Jackson
2022-07-22 12:59     ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 05/18] x86: refactor xen cmdline into general framework Daniel P. Smith
2022-07-19 13:26   ` Jan Beulich
2022-07-22 13:12     ` Daniel P. Smith
2022-07-25  7:09       ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 06/18] fdt: make fdt handling reusable across arch Daniel P. Smith
2022-07-07  1:44   ` Henry Wang
2022-07-19  9:36   ` Jan Beulich
2022-07-22 13:18     ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 07/18] docs: update hyperlaunch device tree documentation Daniel P. Smith
2022-07-18 13:57   ` Smith, Jackson
2022-07-22 13:34     ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 08/18] kconfig: introduce domain builder config option Daniel P. Smith
2022-07-07  1:44   ` Henry Wang
2022-07-19 13:29   ` Jan Beulich
2022-07-22 13:47     ` Daniel P. Smith
2022-07-06 21:04 ` [PATCH v1 09/18] x86: introduce abstractions for domain builder Daniel P. Smith
2022-07-26 14:22   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 10/18] x86: introduce the " Daniel P. Smith
2022-07-18 13:59   ` Smith, Jackson
2022-07-22 14:36     ` Daniel P. Smith
2022-07-22 20:33       ` Smith, Jackson
2022-07-23 10:45         ` Daniel P. Smith
2022-07-26 14:46   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 11/18] x86: initial conversion to " Daniel P. Smith
2022-07-26 15:01   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 12/18] x86: convert dom0 creation " Daniel P. Smith
2022-07-27 12:25   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 13/18] x86: generalize physmap logic Daniel P. Smith
2022-07-27 12:33   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 14/18] x86: generalize vcpu for domain building Daniel P. Smith
2022-07-27 12:46   ` Jan Beulich [this message]
2022-07-06 21:04 ` [PATCH v1 15/18] x86: rework domain page allocation Daniel P. Smith
2022-07-27 13:22   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 16/18] x86: add pv multidomain construction Daniel P. Smith
2022-07-27 14:12   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 17/18] builder: introduce domain builder hypfs tree Daniel P. Smith
2022-07-27 14:30   ` Jan Beulich
2022-07-06 21:04 ` [PATCH v1 18/18] tools: introduce example late pv helper Daniel P. Smith
2022-07-19 17:06 ` [PATCH v1 00/18] Hyperlaunch Smith, Jackson
2022-07-22 14:51   ` Daniel P. Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=481ea371-df3f-287f-5952-262433342f28@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=christopher.clark@starlab.io \
    --cc=dfaggioli@suse.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=george.dunlap@citrix.com \
    --cc=julien@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=scott.davis@starlab.io \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.