On 09.09.2025 11:55, Mykola Kvach wrote: > On Tue, Sep 9, 2025 at 12:14 PM Jan Beulich <[email protected]> wrote: >> On 09.09.2025 10:14, Mykola Kvach wrote: >>> On Tue, Sep 9, 2025 at 9:57 AM Jan Beulich <[email protected]> wrote: >>>> Furthermore with continuing to (ab)use domain_shutdown() also for the >>>> suspend case (Dom0 isn't really shut down when suspending, aiui), you >>>> retain the widening of the issue with the bogus setting of >>>> d->is_shutting_down (and hence the need for later clearing the flag >>>> again) that I mentioned elsewhere. (Yes, I remain of the opinion that >>>> you don't need to sort that as a prereq to your work, yet at the same >>>> time I think the goal should be to at least not make a bad situation >>>> worse.) >>> >>> From the perspective of ARM logic inside Xen, we perform the exact same >>> shutdown steps as for other domains, except that in the end we need to >>> call Xen suspend. >> >> Which, as said, feels wrong. Domains to be revived after resume aren't >> really shut down, so imo they should never have ->is_shutting_down set. > > I believe this is out of scope for this series;
Yes, but see at the bottom. > actually, the same applies to shutdown_code. Not quite sure there. >>> The is_shutting_down flag is easily reset on Xen resume via a >>> domain_resume call, so I don’t see any problems with that. >> >> You did read my earlier mail though, regarding concerns towards the clearing >> of that flag once it was set? (You must have, since iirc you even asked [1] >> whether you're expected to address those issues up front.) > > As far as I understand, this issue is relevant to x86, and I believe > it is out of scope for this series. Yes and ... > See my previous message here: > https://lists.xen.org/archives/html/xen-devel/2025-08/msg02127.html > > I will prepare a separate patch series to address it. ... thanks. My request to not extend the badness remains though, as to the series here. Jan
