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

Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from domain_set_outstanding_pages()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Tue, 10 Jun 2025 19:51:15 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=xOYKum3/hKwNueH2EaNEGHZqmp/D3OcBNiYX/3Aji/Q=; b=WT6cH7wFZ/W6MKQ200ooj9ZcbDX7yCQtcN59oTa2exUIFRoxvW0WYkRHGK4aipRhCThOyz7j8MK8Fup60L+0Gw3L6b4El7BiWtQxeQotz+e8ZTxjEnmAgt+Sh2+OzF0TK+EFC2TpWiRyQTKmN/NwDYmkEFMbDd1r2O9Evj+hfMdZxHQwiUBx2wIPT1kOXBXFGK9w8KWc+T1QBTO6oM3Aj3XPKP0ydIZJ0fKPHStc2DLy0tjk/rwoPQuKM7bYyZV2ZlMI+9skd5wX6luhisbDgmC5G7nfQuKq+KxSMLRGx5gbkSftNMPBJyOQsVmh0+gTOf54mPptgcx0ItNeo8veRw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wWJIwvrKoAwiOlSi+8P8j5SCRB8szyq/qavL3zp5BBZf+cWE2oQk9rIqDyNaHv4digmB5fidl9iKCHrx6vqIgjXUF+I10ZeZDttCuBD8dfYqNmZ0B+ei+fPWrXloMAPqucT/uFVmIfvUPS5q4Q5fqdnHJP3YSQAs3/JuKqd0/zH9rdXT5hGpvGHVtkcsvKeIZUlEEUVjErcF/BJiB1g4WoQ36OU9epljkfi3ghYyeWrOjLQez+clS1/fW8GJef2PU1CmC2vgFXojJqPsUh0VckOf1+IU7j7gvSP5fkoOt0y7niC74fQwTnyuy5wS1mTK+HpFb/xKeRmq982d7FE0Qg==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Bernhard Kaindl <bernhard.kaindl@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 10 Jun 2025 17:51:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue Jun 10, 2025 at 2:23 PM CEST, Jan Beulich wrote:
> On 05.06.2025 18:42, Roger Pau Monné wrote:
>> On Fri, Mar 14, 2025 at 05:24:53PM +0000, Alejandro Vallejo wrote:
>>> With a single global count for the claims it's easy to substract
>>> domain_tot_pages() from the claim so the number given in the hypercall
>>> is the real reservation of the domain. This is the current behaviour.
>>>
>>> However, a later patch introduces exact-node claims and those interact
>>> very poorly with such a scheme. Since accounting domain_tot_pages() in
>>> one case but not the other seems strictly worse than not accounting them
>>> at all (which is at least consistent), this patch stops substracting
>>> tot_pages from the claim and instead checks that claimed memory +
>>> allocated memory don't exceed max_mem.
>> 
>> Hm, while I don't have any specific interest in keeping the current
>> behavior, XENMEM_claim_pages is part of the stable ABI (it's not a
>> domctl), and hence should be stable.
>
> Is that true? It sits inside a
>
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>
> which generally de-marks unstable (tools-only) interfaces.
>
>>  Note also the comment above the
>> definition of XENMEM_claim_pages how it states the specific behavior
>> that you are trying to change (and which should have been adjusted as
>> part of this change).
>
> This is the more important part, imo.

Ugh. I missed that. Regardless, the current scheme is highly counterintuitive
and works only because toolstack colaborates in removing the claim after dom
creation.

>
>> I have no idea why this was made a xenmem rather than a domctl
>> hypercall, but if you want to change the semantics I think the only
>> option is introducing a new hypercall.
>
> It _is_ a memory operation, and it re-uses one of the interface structs
> there. (Yes, none of these would technically have prevented it from
> being a domctl.)
>
> Jan

As Jan mentions, my understanding was that __XEN_TOOLS__ effectively meant
unstable. It is quite hard to keep the previous semantics for one hypercall
while introducing a new one that behaves slightly differently.

Cheers,
Alejandro



 


Rackspace

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