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

Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 29 Jan 2026 18:33:44 +0100
  • 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=eWHjyiGi6yM4GUU8FOEpWD4BhCr0Dthkr0JJUa2/YuU=; b=GmQgGjphKGFKbUkZEpJbxLHhjHGwzlqTjHry1U2GigoMtfYtCSwXIA+WFIZR8VwFheGekXrCbyo+pdUnFM8sFxKfNGDb5B6+QZUtPsSQAupVJGFYHvmEC9+tE71mPsi/bAkxHc4VgXNQf1o6Yb6e5onN3i2c6LuAT+Vcg78lHqPG4YLPswSYo0MSs3h73EqYT7eDu2ZupbczznSWeXMkGT75N2I7RQIoHjpJH3XOMe7TwijIqU3byVeelMzyM+6OpewKY6+T77vUFbzAMQ01Xc8ySHAS6rPk53T1jSzz24A4cQXDY4CJ7LDjDPdNDuOu3QSeLmk9rdEKPbY0Lvcqyg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qK0C72eA66ZCJzqCiNMo7F4Z8WWGEt1mrNKMx7htRLHA//hajPGxHwY01PP0AKAi/7LV6r+ohnrs6Fm/ozDdW4F5EjD07XFjbvZZk0C/+StNrfzx4XJEwzngVZ6j1DCtgO3uYgJlE+LUaJuPgq2ynw9Nw4Q504RYETXkBqYy4HnEwUm9fYhC2JOr9612B6UB99+pltgTUhuTArRWyxlTDwx2bN2vCaYxo8BjaRd+sJfkJF9uSKlrHfBblJc08FPwRoVIWy4hEolWxT63iGjSkxVYZsZOOxr4f7h3j7PpSUki1ifnZRSAz2lrbUgV/bhb51yJ3DmxvO4uCTwMhhmb4g==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Thu, 29 Jan 2026 17:34:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Jan 28, 2026 at 03:34:11PM +0100, Jan Beulich wrote:
> On 28.01.2026 14:33, Roger Pau Monné wrote:
> > On Wed, Jan 28, 2026 at 12:44:26PM +0000, Andrew Cooper wrote:
> >> In principle we could assert that it's already NULL in _domain_destroy()
> >> which might help catch an error if it gets set early but the domain
> >> destroyed before getting into the domlist, but that seems like a rather
> >> slim case.
> > 
> > Given my understanding of the logic in the XENMEM_ hypercalls, I think
> > toolstack can still target domains in the process of being destroyed,
> > at which point we need to keep a final cleanup instance
> > _domain_destroy(), or otherwise adjust XENMEM_populate_physmap
> > hypercall (and others?) so they can't target dying domains.
> 
> Considering that these requests will fail for dying domains because of the
> check in assign_pages(), it may indeed make sense to have another earlier
> check for the purposes here. Otoh doing this early may not buy us very
> much, as the domain may become "dying" immediately after the check. Whereas
> switching stash_allocation()'s if() to
> 
>     if ( d->pending_scrub || d->is_dying )
> 
> looks like it might do.

Oh, I didn't notice the check in assign_pages().

I think a check in stash_allocation() together with a call to
domain_pending_scrub_free() in domain_teardown() (which is after
setting d->is_dying) should be enough to ensure the field is clear
when reaching _domain_destroy().  The call to
domain_pending_scrub_free() in _domain_destroy() can be replaced with
an ASSERT(!d->pending_scrub) then.

Thanks, Roger.



 


Rackspace

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