All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Gavin Shan <gshan@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
	eric.auger@redhat.com, cohuck@redhat.com, zhenyzha@redhat.com,
	richard.henderson@linaro.org, peter.maydell@linaro.org,
	shan.gavin@gmail.com
Subject: Re: [PATCH v4 6/6] hw/arm/virt: Add 'compact-highmem' property
Date: Tue, 04 Oct 2022 18:39:52 +0100	[thread overview]
Message-ID: <86bkqr8p3r.wl-maz@kernel.org> (raw)
In-Reply-To: <20221004002627.59172-7-gshan@redhat.com>

On Tue, 04 Oct 2022 01:26:27 +0100,
Gavin Shan <gshan@redhat.com> wrote:
> 
> After the improvement to high memory region address assignment is
> applied, the memory layout can be changed, introducing possible
> migration breakage. For example, VIRT_HIGH_PCIE_MMIO memory region
> is disabled or enabled when the optimization is applied or not, with
> the following configuration.
> 
>   pa_bits              = 40;
>   vms->highmem_redists = false;
>   vms->highmem_ecam    = false;
>   vms->highmem_mmio    = true;

The question is how are these parameters specified by a user? Short of
hacking the code, this isn't really possible.

> 
>   # qemu-system-aarch64 -accel kvm -cpu host    \
>     -machine virt-7.2,compact-highmem={on, off} \
>     -m 4G,maxmem=511G -monitor stdio
> 
>   Region            compact-highmem=off         compact-highmem=on
>   ----------------------------------------------------------------
>   RAM               [1GB         512GB]        [1GB         512GB]
>   HIGH_GIC_REDISTS  [512GB       512GB+64MB]   [disabled]
>   HIGH_PCIE_ECAM    [512GB+256MB 512GB+512MB]  [disabled]
>   HIGH_PCIE_MMIO    [disabled]                 [512GB       1TB]
> 
> In order to keep backwords compatibility, we need to disable the
> optimization on machines, which is virt-7.1 or ealier than it. It
> means the optimization is enabled by default from virt-7.2. Besides,
> 'compact-highmem' property is added so that the optimization can be
> explicitly enabled or disabled on all machine types by users.

Not directly related to this series, but it seems to me that we should
be aiming at reproducible results across HW implementations (at least
with KVM). Depending on how many PA bits the HW implements, we end-up
with a set of devices or another, which is likely to be confusing for
a user.

I think we should consider an additional set of changes to allow a
user to specify the PA bits as well as the devices they want to see
enabled.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2022-10-04 17:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04  0:26 [PATCH v4 0/6] hw/arm/virt: Improve address assignment for high memory regions Gavin Shan
2022-10-04  0:26 ` [PATCH v4 1/6] hw/arm/virt: Introduce virt_set_high_memmap() helper Gavin Shan
2022-10-04  0:26 ` [PATCH v4 2/6] hw/arm/virt: Rename variable size to region_size in virt_set_high_memmap() Gavin Shan
2022-10-04 10:15   ` Cornelia Huck
2022-10-04  0:26 ` [PATCH v4 3/6] hw/arm/virt: Introduce variable region_base " Gavin Shan
2022-10-04 10:18   ` Cornelia Huck
2022-10-04  0:26 ` [PATCH v4 4/6] hw/arm/virt: Introduce virt_get_high_memmap_enabled() helper Gavin Shan
2022-10-04 10:41   ` Cornelia Huck
2022-10-04 22:47     ` Gavin Shan
2022-10-11 16:45       ` Eric Auger
2022-10-11 23:06         ` Gavin Shan
2022-10-04  0:26 ` [PATCH v4 5/6] hw/arm/virt: Improve high memory region address Gavin Shan
2022-10-04 10:53   ` Cornelia Huck
2022-10-04 22:58     ` Gavin Shan
2022-10-04  0:26 ` [PATCH v4 6/6] hw/arm/virt: Add 'compact-highmem' property Gavin Shan
2022-10-04 17:39   ` Marc Zyngier [this message]
2022-10-04 23:33     ` 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=86bkqr8p3r.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=gshan@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.