qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Andrew Jones <drjones@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org,
	eric.auger@redhat.com, kernel-team@android.com,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v3 3/5] hw/arm/virt: Honor highmem setting when computing the memory map
Date: Fri, 7 Jan 2022 18:48:16 +0000	[thread overview]
Message-ID: <CAFEAcA8KCZFfiYA_AAxA-ChfN5vZd7EF1jGcFxmcpq=fi4ToeQ@mail.gmail.com> (raw)
In-Reply-To: <87y23rtnny.wl-maz@kernel.org>

On Fri, 7 Jan 2022 at 18:18, Marc Zyngier <maz@kernel.org> wrote:
> This is a chicken and egg problem: you need the IPA size to compute
> the memory map, and you need the memory map to compute the IPA
> size. Fun, isn't it?
>
> At the moment, virt_set_memmap() doesn't know about the IPA space,
> generates a highest_gpa that may not work, and we end-up failing
> because the resulting VM type is out of bound.
>
> My solution to that is to feed the *maximum* IPA size to
> virt_set_memmap(), compute the memory map there, and then use
> highest_gpa to compute the actual IPA size that is used to create the
> VM. By knowing the IPA limit in virt_set_memmap(), I'm able to keep it
> in check and avoid generating an unusable memory map.

Is there any reason not to just always create the VM with the
maximum supported IPA size, rather than trying to create it
with the smallest IPA size that will work? (ie skip the last
step of computing the IPA size to create the VM with)

-- PMM


  reply	other threads:[~2022-01-07 19:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 21:16 [PATCH v3 0/5] target/arm: Reduced-IPA space and highmem=off fixes Marc Zyngier
2021-12-27 21:16 ` [PATCH v3 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam Marc Zyngier
2021-12-27 21:16 ` [PATCH v3 2/5] hw/arm/virt: Add a control for the the highmem redistributors Marc Zyngier
2021-12-27 21:16 ` [PATCH v3 3/5] hw/arm/virt: Honor highmem setting when computing the memory map Marc Zyngier
2022-01-05  9:22   ` Eric Auger
2022-01-05  9:36     ` Eric Auger
2022-01-06 21:26     ` Marc Zyngier
2022-01-07 17:15       ` Eric Auger
2022-01-07 18:18         ` Marc Zyngier
2022-01-07 18:48           ` Peter Maydell [this message]
2022-01-07 19:04             ` Marc Zyngier
2021-12-27 21:16 ` [PATCH v3 4/5] hw/arm/virt: Use the PA range to compute " Marc Zyngier
2021-12-27 21:16 ` [PATCH v3 5/5] hw/arm/virt: Disable highmem devices that don't fit in the PA range Marc Zyngier

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='CAFEAcA8KCZFfiYA_AAxA-ChfN5vZd7EF1jGcFxmcpq=fi4ToeQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=drjones@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=maz@kernel.org \
    --cc=qemu-devel@nongnu.org \
    /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).