qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: Gavin Shan <gshan@redhat.com>, qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org, maz@kernel.org, cohuck@redhat.com,
	zhenyzha@redhat.com, richard.henderson@linaro.org,
	peter.maydell@linaro.org, shan.gavin@gmail.com
Subject: Re: [PATCH v5 5/6] hw/arm/virt: Improve high memory region address assignment
Date: Wed, 19 Oct 2022 22:07:02 +0200	[thread overview]
Message-ID: <73b398c9-52d7-88fa-7e84-f9ed082799b0@redhat.com> (raw)
In-Reply-To: <20221011231832.149839-6-gshan@redhat.com>

Hi Gavin

On 10/12/22 01:18, Gavin Shan wrote:
> There are three high memory regions, which are VIRT_HIGH_REDIST2,
> VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
> are floating on highest RAM address. However, they can be disabled
> in several cases.
>
> (1) One specific high memory region is disabled by developer by
>     toggling vms->highmem_{redists, ecam, mmio}.
I would replace the above sentence by

One specific high memory region is likely to be disabled by the code by toggling vms->highmem_{redists, ecam, mmio}:

>
> (2) VIRT_HIGH_PCIE_ECAM region is disabled on machine, which is
>     'virt-2.12' or ealier than it.
>
> (3) VIRT_HIGH_PCIE_ECAM region is disabled when firmware is loaded
>     on 32-bits system.
>
> (4) One specific high memory region is disabled when it breaks the
>     PA space limit.
>
> The current implementation of virt_set_memmap() isn't comprehensive
> because the space for one specific high memory region is always
> reserved from the PA space for case (1), (2) and (3).
I would suggest:
isn't optimized because the high memory region PA range is always

reserved whatever the actual state of the corresponding vms->highmem_
* flag.

>  In the code,
> 'base' and 'vms->highest_gpa' are always increased for those three
> cases. It's unnecessary since the assigned space of the disabled
> high memory region won't be used afterwards.
>
> This improves the address assignment for those three high memory
s/This improves/Improve
> region by skipping the address assignment for one specific high
> memory region if it has been disabled in case (1), (2) and (3).
> 'vms->high_compact' is false for now, meaning that we don't have
s/hight_compat/highmem_compact

You also may justify the introduction of this new field.
> any behavior changes until it becomes configurable through property
> 'compact-highmem' in next patch.
>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
> ---
>  hw/arm/virt.c         | 23 +++++++++++++++--------
>  include/hw/arm/virt.h |  1 +
>  2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ee98a8a3b6..c05cfb5314 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1717,22 +1717,29 @@ static void virt_set_high_memmap(VirtMachineState *vms,
>          region_base = ROUND_UP(base, extended_memmap[i].size);
>          region_size = extended_memmap[i].size;
>  
> -        vms->memmap[i].base = region_base;
> -        vms->memmap[i].size = region_size;
> -
>          /*
>           * Check each device to see if they fit in the PA space,
while we are at it, you can change s/they fit/it fits
> -         * moving highest_gpa as we go.
> +         * moving highest_gpa as we go. For compatibility, move
> +         * highest_gpa for disabled fitting devices as well, if
> +         * the compact layout has been disabled.
>           *
>           * For each device that doesn't fit, disable it.
>           */
>          fits = (region_base + region_size) <= BIT_ULL(pa_bits);
> -        if (fits) {
> +        if (*region_enabled && fits) {
> +            vms->memmap[i].base = region_base;
> +            vms->memmap[i].size = region_size;
>              vms->highest_gpa = region_base + region_size - 1;
> +            base = region_base + region_size;
> +        } else {
> +            *region_enabled = false;
> +            if (!vms->highmem_compact) {
> +                base = region_base + region_size;
> +                if (fits) {
> +                    vms->highest_gpa = region_base + region_size - 1;
> +                }
> +            }
>          }
> -
> -        *region_enabled &= fits;
> -        base = region_base + region_size;
>      }
>  }
This looks quite complicated to me. It is not obvious for instance we
have the same code as before when highmem_compact is not set. Typically

vms->memmap[i].base/size are not always set as they were to be and impact on the rest of the code must be double checked.

Could this be rewritten in that way (pseudocode totally untested).


static void fit_highmem_slot(vms, *base, i, pa_bits)
{
    region_enabled = virt_get_high_memmap_enabled(vms, i);
    region_base = ROUND_UP(*base, extended_memmap[i].size);
    region_size = extended_memmap[i].size;
    fits = (region_base + region_size) <= BIT_ULL(pa_bits);
    *region_enabled &= fits;
    vms->memmap[i].base = region_base;
    vms->memmap[i].size = region_size;

    /* compact layout only allocates space for the region if this latter
is enabled & fits*/
    if (vms->highmem_compact && !region_enabled) {
        return;
    }

    /* account for the region and update the base address/highest_gpa if
needed*/ 
    *base = region_base + region_size;
    if (fits) { 
        vms->highest_gpa = *base - 1;
    }
}

static void virt_set_high_memmap(VirtMachineState *vms,
                                 hwaddr base, int pa_bits)
{
    hwaddr region_base, region_size;
    bool *region_enabled, fits;
    int i;

    for (i = VIRT_LOWMEMMAP_LAST; i < ARRAY_SIZE(extended_memmap); i++) {
        /* we do not break in case the region does not fit since
fit_highmem_slot also updates the enabled status of the region */
        fit_highmem_slot(vms, &base, i, pa_bits);
    }
}

>  
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 6ec479ca2b..709f623741 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -144,6 +144,7 @@ struct VirtMachineState {
>      PFlashCFI01 *flash[2];
>      bool secure;
>      bool highmem;
> +    bool highmem_compact;
>      bool highmem_ecam;
>      bool highmem_mmio;
>      bool highmem_redists;
Thanks

Eric



  parent reply	other threads:[~2022-10-19 20:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 23:18 [PATCH v5 0/6] hw/arm/virt: Improve address assignment for high memory regions Gavin Shan
2022-10-11 23:18 ` [PATCH v5 1/6] hw/arm/virt: Introduce virt_set_high_memmap() helper Gavin Shan
2022-10-11 23:18 ` [PATCH v5 2/6] hw/arm/virt: Rename variable size to region_size in virt_set_high_memmap() Gavin Shan
2022-10-11 23:18 ` [PATCH v5 3/6] hw/arm/virt: Introduce variable region_base " Gavin Shan
2022-10-11 23:18 ` [PATCH v5 4/6] hw/arm/virt: Introduce virt_get_high_memmap_enabled() helper Gavin Shan
2022-10-19 13:50   ` Cornelia Huck
2022-10-20  4:57   ` Eric Auger
2022-10-11 23:18 ` [PATCH v5 5/6] hw/arm/virt: Improve high memory region address assignment Gavin Shan
2022-10-19 13:54   ` Cornelia Huck
2022-10-19 20:07   ` Eric Auger [this message]
2022-10-19 22:58     ` Gavin Shan
2022-10-11 23:18 ` [PATCH v5 6/6] hw/arm/virt: Add 'compact-highmem' property Gavin Shan
2022-10-19 14:00   ` Cornelia Huck
2022-10-19 23:08     ` Gavin Shan
2022-10-19 20:18   ` Eric Auger
2022-10-19 23:57     ` Gavin Shan
2022-10-20  9:44       ` Marc Zyngier
2022-10-20 11:13         ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73b398c9-52d7-88fa-7e84-f9ed082799b0@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=gshan@redhat.com \
    --cc=maz@kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shan.gavin@gmail.com \
    --cc=zhenyzha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).