[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC] x86+libxl: correct p2m (shadow) memory pool size calculation
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Fri, 22 Apr 2022 17:48:27 +0200
- 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=arcselector9901; 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=sd/I353whyT6eDqonLgykwRUjWz+3qq0b6Tk9+xDv7g=; b=HzLUTbuzaVivMW/3rDlHo4aRhdNyQ3b605VpxsHpHRI3WbkZJi0k/rfPnCKWw/bYsHiiPgz6M0t5xMqWB/H4CfNecGoiIeoHnqHRWhaDAJsyhtC3i0QnbPgKGEUlgNeaWJwJJfM88jlsBQI/bxElHvdiuZ8WtKa3bzv8IXQ6pJKIieSFueEFsw5aNJPeAJ1zpchd2/V5qcU8Y7w91mToneaf5I36+0YIEnheT+beZFTJ5BuoUZ9NAevncK9xqKejtUwVUdDwJ6QaYGdcsyDQMtej2W397Wqodpl3EO72Kz+qqMnvkrUxBhntLjLbdp6BoPHoh4IUivlgS7jjjGaxiw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xnjq0KEDHHPmMmvI3AwUY9vLB/9qWqKfz6b1avEweEeeXbBbFTqc8JQnY8lMyr3eqlsYq9d8lIpoc3IFWc8oyp47HPSV+jR4Oky77TSB7DKNigmk2gavPyZfQOYWT+Yb7ONyqVeHqVL2WMoF2b4LxDnYHyNfQW6Ggrl1nLMPeO/rTXVrIC8//cbyXvSPC0UuF0UFxAem9i3PbXoG0SIGkBhRITG37ZPOb2x8tguh22ZXK3/0dTNDGtVkl4uhnmKyxbb5mUqV0Tbf10Ydj3wG6IC7LgzE3mkfE5CrjoNgfzvZmQchIi8u8T/T4TjpnOptUzEHrPLfPwrux/TqadFT6Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
- Delivery-date: Fri, 22 Apr 2022 15:48:44 +0000
- Ironport-data: A9a23:KOleaarmHQG6Hj26JYRqFdBrf2ZeBmIfZBIvgKrLsJaIsI4StFCzt garIBmAPvzfZmLxL95yaIWw9UlS6sKEyddnTlZp/y5kE39A85uZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefQAOCU5NfsYkidfyc9IMsaoU8lyrZRbrJA24DjWVvR4 4mq+aUzBXf+s9JKGjNMg068gEsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf M7RzanRw4/s10xF5uVJMFrMWhZirrb6ZWBig5fNMkSoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBYofxmv0jAzdhCQ5UZPUcpueaPmmnmJnGp6HGWyOEL/RGKmgTZNVd39ktRGZE+ LofNSwHaQ2Fi6Su2rWnR+Jwh8Mlas72IIcYvXImxjbcZRokacmbH+OWupkFgXFp3psm8fX2P qL1bRJ1axvNeVtXM0o/A5Mihua4wHL4dlW0rXrL9PdmuTaOnGSd1pDqPcTXfICWH/lS3U+Uj DvKzmHFIzMVYYn3JT2ttyjEavX0tSHxVZ8WFba43uV3m1DVzWsWYDUGWF3+rfSnh0qWX9NEN 1dS6icotbI19kGgUp/6RRLQiGGAlg4RXZxXCeJSwAOC0K3P+C6CG3MJCDVGbbQbWNQeQDUr0 hqMgInvDDk26LmNEyvFrfGTsC+4PjUTISkafygYQAAZ4t7l5oYukhbISdUlG6mw5jHoJQzNL /mxhHBWr90uYQQjjc1XIXivb+qQm6X0
- Ironport-hdrordr: A9a23:FcVUD66o5KFaBo5x9wPXwVqBI+orL9Y04lQ7vn2ZFiY5TiXIra qTdaogviMc6Ax/ZJjvo6HkBEClewKlyXcT2/hrAV7CZniehILMFu1fBOTZowEIdxeOldK1kJ 0QCZSWa+eAcmSS7/yKhzVQeuxIqLfnzEnrv5a5854Ed3AXV0gK1XYcNu/0KDwVeOEQbqBJaa Z0q/A37gaISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oC5BOVhT2lxbbmG1zAty1uGA9n8PMHyy zoggb57qKsv7WSzQLd7Xba69BzlMH6wtVOKcSQgow+KynqiCyveIN9Mofy9AwdkaWK0hIHgd PMqxAvM4Ba7G7QRHi8pV/X1wzpwF8Vmgvf4G7dpUGmjd3yRTo8BcYEr5leaAHl500pu8w5+L 5X3kqC3qAnQi/orWDY3ZzlRhtqnk27rT4JiugIlUFSVoMYdft4sZEfxkVIC50NdRiKpLzPKN MeTf002cwmMW9zNxvizypSKZ2XLzkO9y69MwY/Upf/6UkVoJh7p3FosfD30E1wsa7VcKM0lt gsAp4Y6o2mcfVmHZ6VJN1xNvdfWVa9Ny4lDgqpUCfaPZBCHU7xgLjKx5hwzN2WWfUzvekPcd L6IRlliVI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Apr 22, 2022 at 01:56:17PM +0200, Jan Beulich wrote:
> On 22.04.2022 13:14, Roger Pau Monné wrote:
> > On Fri, Apr 22, 2022 at 12:57:03PM +0200, Jan Beulich wrote:
> >> The reference "to shadow the resident processes" is applicable to
> >> domains (potentially) running in shadow mode only. Adjust the
> >> calculations accordingly.
> >>
> >> In dom0_paging_pages() also take the opportunity and stop open-coding
> >> DIV_ROUND_UP().
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> ---
> >> RFC: I'm pretty sure I can't change a public libxl function (deprecated
> >> or not) like this, but I also don't know how I should go about
> >> doing so (short of introducing a brand new function and leaving the
> >> existing one broken).
> >
> > You have to play with LIBXL_API_VERSION, see for example:
> >
> > 1e3304005e libxl: Make libxl_retrieve_domain_configuration async
> >
> >>
> >> --- a/tools/include/libxl_utils.h
> >> +++ b/tools/include/libxl_utils.h
> >> @@ -23,7 +23,10 @@ const
> >> #endif
> >> char *libxl_basename(const char *name); /* returns string from strdup */
> >>
> >> -unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb,
> >> unsigned int smp_cpus);
> >> +unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb,
> >> + unsigned int smp_cpus,
> >> + libxl_domain_type type,
> >> + bool hap);
> >
> > Iff we are to change this anyway, we might as well rename the
> > function and introduce a proper
> > libxl_get_required_{paging,p2m}_memory?
> >
> > It seems wrong to have a function explicitly named 'shadow' that takes
> > a 'hap' parameter.
> >
> > If you introduce a new function there's no need to play with the
> > LIBXL_API_VERSION and you can just add a new LIBXL_HAVE_FOO define.
>
> With the original function deprecated, I don't see why I'd need to
> make a new public function - my fallback plan was (as also suggested
> by Jürgen) to make a new internal function.
Yes, that would be fine if there's no need to expose the new function
for external callers.
Thanks, Roger.
|
