[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] xen: Introduce non-broken hypercalls for the p2m pool size
- To: Julien Grall <julien@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 27 Oct 2022 08:56:31 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=vCY7I2ZdJgT2X3NvZlqbK5kIo0Sa6ZEyRPlwJhig8p0=; b=U7p/v9NbOgaHpf2PEklIIrH7pxgWP5iVKDM6ayAph2VsEeMnaPzsi2zGzRqlF5mDLxgHIa0IL8ZDRhBLc2DBT/C4FxSkkr/0CnrmSJqsnWEJDTYRktDPRjec5uI4lh0VMUbzIgdKAtAUO4yamE93RAk/45OwV5rdpWeSf4Gm6iTBeVi/6KuBUVApmKiw3oVKU6yEpDHpjH4LG7Zm4ddtugg9ZVp6U6cAu/qYkOpo1Pvq1P6RiJk2SnFyIoP/dlL2KYS9Cp/EWFBtKDJ1aKyZn7rjvrruKBt79kR7dDjFOWJpU5nFyFnpFp/fHFqa9QKMgD+/cgca+x79MQG3jaeskg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AQGVI7nFT9T3JjaAGbHGzWx+W6ybkBnVPBkB8k38VFkF2qRqMbvCpvM4RivwxfWaxfxLnu0v+9woQvAGDcrCtIXUISFS4Y2Goeey+zUo6/VNjaPHwjIrPFyU/bvU1reUPmBCtmrzDQzZtj4x3c8y9fgmIZPVfYDLRfVfHQ5xIqg2VjC8RnEV00OOcxP3pS12oW1hofOFDAj2hvB6IlZv9aXa22NrMtM4KIYlr3Xq4LxNszB1Dxe3DaPsqoJN6I6qsr6pGqNs7P/8bHnm2ik4mbjmkzI0Ubwq9udyUV7tGDZfgZ1e9FM1OZbMsKB9NaM4EtPXrDhzksb7eq/0XOf+6Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Delivery-date: Thu, 27 Oct 2022 06:56:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26.10.2022 23:24, Julien Grall wrote:
> On 26/10/2022 20:22, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/mm/hap/hap.c
>>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>>> @@ -345,6 +345,16 @@ unsigned int hap_get_allocation(struct domain *d)
>>>> + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
>>>> }
>>>>
>>>> +int hap_get_allocation_bytes(struct domain *d, uint64_t *size)
>>>> +{
>>>> + unsigned long pages = (d->arch.paging.hap.total_pages +
>>>> + d->arch.paging.hap.p2m_pages);
>>> Unlike for Arm no ACCESS_ONCE() here? Also the addition can in
>>> principle overflow, because being done only in 32 bits.
>>
>> I'm not actually convinced ARM needs ACCESS_ONCE() to begin with. I
>> can't see any legal transformation of that logic which could result in a
>> torn load.
>
> AFAIU, ACCESS_ONCE() is not only about torn load but also making sure
> that the compiler will only read the value once.
>
> When LTO is enabled (not yet supported) in Xen, can we guarantee the
> compiler will not try to access total_pages twice (obviously it would be
> caller dependent)?
Aren't all accesses (supposed to be) under paging lock? At which point
there's no issue with multiple (or torn) accesses?
Jan
|
