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

Re: [PATCH] xen/domain: make shutdown state explicit


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Mykola Kvach <xakep.amatop@xxxxxxxxx>
  • Date: Tue, 24 Mar 2026 12:00:00 +0200
  • Arc-authentication-results: i=1; mx.google.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ar1bjqW5Lo0tgcZE6DdGTP/006Egrh4tUuj0RN0FzWo=; fh=ZqQ1W4s2sAoJbRyzgY8rmX9kckACA2A930LY2DVXlfc=; b=i1u7bakG/N3YwpvMf03J+I33gj8mtCd/JsxV/kl1/A/+rnIhUEmvVNe/uG+a9YVVFe NvuXzOf7SHLqjFWx5aRw9PniM67qbLkwg03NKPDjG7b7t/9YHgS4HyaYxcUJWS8r0UPx W5m/BO1szHEAk+98TqxVhCJoREuTFhOL8rB6V3Q2Nmww9yuYu3xVeeq+9Uyn77e2IxU/ T7y/3NkWjRgmBfJXeZGPjwiz3G3iWIFhoFxyd89ZRn1G7e463mmMU/D7WKeSv6OjQ49M b77zuZ0na/M4eGW+zQw/Pgy9W+yH0EJ4wiT9U+kvp5MaVmK9Z/BFNclfwpq3U+vXdscG GnYg==; darn=lists.xenproject.org
  • Arc-seal: i=1; a=rsa-sha256; t=1774346421; cv=none; d=google.com; s=arc-20240605; b=C/wb4elKdp+Ha0KL8O9taextno0BFoRrG9GObsf3ZMYWup95RIsIZrO2P1giRToyiD Hn8q2TJyMbvEyRxj4u8WBJGVNCka3f3bHArBhJpK0k8D7P6dbbSEi4hv2mjd9r0jhEPp n8UveL15H6SOMkKUhHenMl0XlmXcRQUiZw0YwdbEGrCia6DWH/KlrRQV0LEHYQ8nb06i nbcUAFDMxFKlXXjKAkZrSI84FtahcVt0xquedsMDFouyskdO37Y+9oIMI+ACAl/+mmEL j9o0RqsrdBONJTm7wGaBfPV5lXjzJh4YkQSe31iNO/5YMZnBOAbXZe7kN9UtLmrmPW7i zzwQ==
  • Cc: Mykola Kvach <mykola_kvach@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 24 Mar 2026 10:00:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Jan,

Thank you for the review.

On Thu, Mar 19, 2026 at 12:32 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 19.03.2026 00:25, Mykola Kvach wrote:
> > From: Mykola Kvach <mykola_kvach@xxxxxxxx>
> >
> > The domain shutdown flow currently overloads is_shutting_down and
> > is_shut_down to represent multiple phases of the shutdown lifecycle,
> > while some users treat is_shutting_down as a broader "domain is no
> > longer normal" condition.
> >
> > Make the shutdown lifecycle explicit by introducing
> > enum domain_shutdown_state and converting the existing users to helper
> > predicates describing whether shutdown is in progress, complete, or
> > active.
>
> Mind me asking what the distinction is between "active" and "in progress"?
> They feel like synonyms to me. To me "is shutting down" vs "was shut down"
> would be the clearer distinction (i.e. domain_shutting_down() and
> domain_shut_down() or some such, albeit for the latter I could also live
> with domain_shutdown_complete() as you have it, or maybe slightly less
> ambiguously domain_shutdown_completed()). Yet then I'm not a native
> speaker.

Yes, the distinction I was trying to make is:

  - in progress: shutdown has been initiated, but not all vCPUs may
    have reached the paused-for-shutdown state yet

  - complete: shutdown has been finalized, i.e. all vCPUs are paused
    and the domain is fully shut down

  - active: a shorthand for "shutdown_state != none", i.e. covering
    both of the above

So "active" was meant as a broader "the domain is already in shutdown
state", rather than as a synonym for "shutdown is currently progressing".

>
> Further, I can't quite derive upon what criteria you chose whether
> ->is_shutting_down checks are to be converted to domain_shutdown_active()
> vs domain_shutdown_in_progress(). This could do with writing down. (It
> also might be easier with the suggested alternative naming.)

Likewise, the conversions from is_shutting_down/is_shut_down were not
meant to be mechanical. The criterion I used was:

  - domain_shutdown_in_progress() where the code cares specifically
    about the transient phase before shutdown is fully finalized

  - domain_shutdown_complete() where the code is specifically about
    the fully shut down state being reported or tested

  - domain_shutdown_active() where the old logic was effectively using
    the combined condition "the domain is already somewhere in the
    shutdown lifecycle"

One detail which likely wasn't obvious from the patch is that the old
flags were not mutually exclusive. Once is_shut_down became true,
is_shutting_down still remains set as well.

Because of that, the conversion was not just about replacing old
is_shutting_down checks. I also had to account for sites using
is_shut_down explicitly, so that the resulting logic would preserve the
old distinctions between the in-progress, complete, and combined cases.

In particular, old !is_shutting_down checks implicitly excluded both
the in-progress and fully shut down states. Those are the places where
I used domain_shutdown_active(). Sites specifically testing the fully
shut down state were converted to domain_shutdown_complete(), while the
ones caring about the transient shutdown phase were converted to
domain_shutdown_in_progress().

vcpu_check_shutdown() is an example of the latter. That path exists to
drive a shutdown already in flight to completion: it may still need to
pause this vCPU, clear defer_shutdown, and then re-check whether
shutdown can now be finalized. Once shutdown is already complete,
there is nothing left for that path to do, so using the broader
combined state there would not be appropriate.

I agree this selection criterion is not obvious enough from the patch
as posted. I'll make that rationale explicit in the commit message.


If you think naming is part of the confusion, I could switch to
something along these lines instead:

  - domain_shutting_down()      for the in-progress state
  - domain_shutdown_completed() for the finalized state
  - domain_in_shutdown_state()  for the union of both

Would that look better to you?

>
> > @@ -1444,9 +1458,17 @@ void domain_resume(struct domain *d)
> >          v->paused_for_shutdown = 0;
> >      }
> >
> > +out_unlock:
>
> Nit (style): Labels indented by at least one blank please.

Ack.

Best regards,
Mykola

>
> Jan

 


Rackspace

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