[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/8] x86/paging: fold HAP and shadow memory alloc related fields
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Wed, 21 Dec 2022 13:49:17 +0000
- Accept-language: en-GB, en-US
- 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=3uoNZX2mf0/RXAhrZp96GWhUXLYGz3XFWetNqWH/k2c=; b=bIJQxgA9h5vKwJxWTSGR/LcNepDrVQCfAuqqPzF5/KlnVTHBjU0ZZieuyOcpRDO9hQODDclkuDbg4iWbxbdOyK5uNMzyaVCBFzASjz49UOslhTy4L6KZgFodn3jFt0pyxT9xgxW5Psm0bs4bbJVL7cVdjeuilDlb29pJONh/g0B191RsZ9ccSycJNpMByKC3So17f9A1l3C2vpFsxSTY8612Gbyc2OuMUXqwJUXDg2tyUoOqtI+0wzutOw8/3yXkf5+5DYyU2KNU2L1a7jZxXyPQU/6NcTj0RlDGRa3DwCSUXZsX0Gbgquf/1q784YVNHirU1GgqFz02+J7Ro490iw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h7ehrLXtvFEvglXn2zjdTznj86nq2EoU9LiCwoFtTJ0q//pXLtk14IMvWv7YJaRZ2hEIGGg2VVCJnQj/L6Qf0Wc+4xqTcBtRN9DnDzNWPHg33dk2YugM8ZDGcMvPfWmDyQJizd/+GVdLdWQjcuSqUF9HjjH38Cj+61OnFTyuMjCr2DW+Lutu6RKHhexnC8dtTA4ADpu3eqJAtCNqSFmp7/dZCz83S9NIzyvWDnbpCPGlyyIIUFG57PlP3qKHIk8oH0C68dX66zFa/xF6pO1eBAuRC11y7GwTdpbVwbDNMxsvda0edgNp9px/lGx/J/mcCuJNsMD68uE7DYNy4S6FIA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>
- Delivery-date: Wed, 21 Dec 2022 13:49:38 +0000
- Ironport-data: A9a23:OZumd6AfuqyJCRVW/xjiw5YqxClBgxIJ4kV8jS/XYbTApDshhGBWm GRKDTiEaf/cNGqhedxyOdnj8B4P7MXXztRqQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48T8nk/nNHuCnYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbyRFtcpvlDs15K6o4WlC5wRkDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIw5Oh6HmZWx awjGnMBTzKSg/2ymbyec7w57igjBJGD0II3nFhFlGucJ9B2BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTI+OxuvDe7IA9ZidABNPL8fNCQSNoTtUGfv m/cpEzyAw0ANczZwj2Amp6prr+fzHyrCNNJfFG+3qRjqlHNz1M9NCwLfBikgvLgzUG8B90Kf iT4/QJr98De7neDTNPwQhm5q36spQMHVpxbFOhSwBGAzO/Y7hiUAkAATyVdc5o2uckuXzso2 1SV2dTzClRHr7m9WX+bsLCOoluaJSkQBX8PY2kDVwRt3jX4iIQ6jxaKRNAzFqew14fxAWupn G/MqzUijbIOi8JNz7+84V3MnzOroN7OUxIx4QLUGGmi62uVebKYWmBh0nCDhd4oEWpTZgPpU KQs8yRG0N0zMA==
- Ironport-hdrordr: A9a23:gQDXV6HWFYsSPtd8pLqE2ceALOsnbusQ8zAXPhZKOHlom62j5r uTdZEgv3LJYVkqKRYdcLy7SdC9qBDnlKKdg7NhWYtKNTOO0ACVxedZnOjfKhLbak/DH4VmpM FdmsZFeaXN5JtB4voSIjPVLz/t+re6GWmT5dvj8w==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZFT+bjE/YAX9/X0eeHf49kbkoQK54W4gA
- Thread-topic: [PATCH 1/8] x86/paging: fold HAP and shadow memory alloc related fields
On 21/12/2022 1:24 pm, Jan Beulich wrote:
> Especially with struct shadow_domain and struct hap_domain not living in
> a union inside struct paging_domain, let's avoid the duplication: The
> fields are named and used in identical ways, and only one of HAP or
> shadow can be in use for a domain. This then also renders involved
> expressions slightly more legible.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, with two minor
suggestions.
> ---
> Quite likely more folding of code is possible with this. For example
> {hap,shadow}_set_allocation() are now yet more similar than they already
> were.
TBH, I think it wants to go further still. paging_mempool was
intentionally common because all HAP architectures need it, and I really
don't want to be playing XSA-410 with every new architecture.
But this is fine to defer until further work.
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -179,10 +173,6 @@ struct shadow_vcpu {
> /* hardware assisted paging */
> /************************************************/
> struct hap_domain {
> - struct page_list_head freelist;
> - unsigned int total_pages; /* number of pages allocated */
> - unsigned int free_pages; /* number of pages on freelists */
> - unsigned int p2m_pages; /* number of pages allocated to p2m */
> };
Do we want to drop hap_domain? I can't forsee needing to put anything
back into it.
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -979,17 +980,17 @@ int __init paging_set_allocation(struct
>
> int arch_get_paging_mempool_size(struct domain *d, uint64_t *size)
> {
> - int rc;
> + unsigned long pages;
>
> if ( is_pv_domain(d) ) /* TODO: Relax in due course */
> return -EOPNOTSUPP;
>
> - if ( hap_enabled(d) )
> - rc = hap_get_allocation_bytes(d, size);
> - else
> - rc = shadow_get_allocation_bytes(d, size);
> + pages = d->arch.paging.total_pages;
> + pages += d->arch.paging.p2m_pages;
Any chance I can talk you into having a second space before the =, so we
get:
pages = d->arch.paging.total_pages;
pages += d->arch.paging.p2m_pages;
nicely aligned vertically?
~Andrew
|
