From: Marc Zyngier <maz@kernel.org>
To: eric.auger@redhat.com
Cc: qemu-devel@nongnu.org, Andrew Jones <drjones@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam
Date: Thu, 06 Jan 2022 19:34:57 +0000 [thread overview]
Message-ID: <8735m0zmhq.wl-maz@kernel.org> (raw)
In-Reply-To: <cb9f6c39-40f8-eea7-73bf-13df1e5dae9d@redhat.com>
Hi Eric,
On Wed, 05 Jan 2022 09:41:19 +0000,
Eric Auger <eric.auger@redhat.com> wrote:
>
> couldn't you simply introduce highmem_redist which is truly missing. You
> could set it in virt_set_memmap() in case you skip extended_map overlay
> and use it in virt_gicv3_redist_region_count() as you did?
> In addition to the device memory top address check against the 4GB limit
> if !highmem, we should be fine then?
No, highmem really isn't nearly enough.
Imagine you have (like I do) a system with 36 bits of IPA space.
Create a VM with 8GB of RAM (which means the low-end of IPA space is
already 9GB). Obviously, highmem=true here. With the current code, we
will try to expose this PCI MMIO range, which falls way out of the IPA
space (you need at least 40 bits of IPA to even cover it with the
smallest configuration).
highmem really is a control that says 'things may live above 4GB'. It
doesn't say *how far* above 4GB it can be placed. Which is what I am
trying to address.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: eric.auger@redhat.com
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam
Date: Thu, 06 Jan 2022 19:34:57 +0000 [thread overview]
Message-ID: <8735m0zmhq.wl-maz@kernel.org> (raw)
In-Reply-To: <cb9f6c39-40f8-eea7-73bf-13df1e5dae9d@redhat.com>
Hi Eric,
On Wed, 05 Jan 2022 09:41:19 +0000,
Eric Auger <eric.auger@redhat.com> wrote:
>
> couldn't you simply introduce highmem_redist which is truly missing. You
> could set it in virt_set_memmap() in case you skip extended_map overlay
> and use it in virt_gicv3_redist_region_count() as you did?
> In addition to the device memory top address check against the 4GB limit
> if !highmem, we should be fine then?
No, highmem really isn't nearly enough.
Imagine you have (like I do) a system with 36 bits of IPA space.
Create a VM with 8GB of RAM (which means the low-end of IPA space is
already 9GB). Obviously, highmem=true here. With the current code, we
will try to expose this PCI MMIO range, which falls way out of the IPA
space (you need at least 40 bits of IPA to even cover it with the
smallest configuration).
highmem really is a control that says 'things may live above 4GB'. It
doesn't say *how far* above 4GB it can be placed. Which is what I am
trying to address.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: eric.auger@redhat.com
Cc: Peter Maydell <peter.maydell@linaro.org>,
Andrew Jones <drjones@redhat.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam
Date: Thu, 06 Jan 2022 19:34:57 +0000 [thread overview]
Message-ID: <8735m0zmhq.wl-maz@kernel.org> (raw)
In-Reply-To: <cb9f6c39-40f8-eea7-73bf-13df1e5dae9d@redhat.com>
Hi Eric,
On Wed, 05 Jan 2022 09:41:19 +0000,
Eric Auger <eric.auger@redhat.com> wrote:
>
> couldn't you simply introduce highmem_redist which is truly missing. You
> could set it in virt_set_memmap() in case you skip extended_map overlay
> and use it in virt_gicv3_redist_region_count() as you did?
> In addition to the device memory top address check against the 4GB limit
> if !highmem, we should be fine then?
No, highmem really isn't nearly enough.
Imagine you have (like I do) a system with 36 bits of IPA space.
Create a VM with 8GB of RAM (which means the low-end of IPA space is
already 9GB). Obviously, highmem=true here. With the current code, we
will try to expose this PCI MMIO range, which falls way out of the IPA
space (you need at least 40 bits of IPA to even cover it with the
smallest configuration).
highmem really is a control that says 'things may live above 4GB'. It
doesn't say *how far* above 4GB it can be placed. Which is what I am
trying to address.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-01-06 19:35 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-03 16:46 [PATCH v2 0/5] target/arm: Reduced-IPA space and highmem=off fixes Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-04 9:41 ` Andrew Jones
2021-10-04 9:41 ` Andrew Jones
2021-10-04 9:41 ` Andrew Jones
2021-10-04 12:00 ` Eric Auger
2021-10-04 12:00 ` Eric Auger
2021-10-04 12:00 ` Eric Auger
2021-12-27 15:53 ` Marc Zyngier
2021-12-27 15:53 ` Marc Zyngier
2021-12-27 15:53 ` Marc Zyngier
2022-01-04 15:31 ` Eric Auger
2022-01-04 15:31 ` Eric Auger
2022-01-04 15:31 ` Eric Auger
2022-01-04 22:15 ` Marc Zyngier
2022-01-04 22:15 ` Marc Zyngier
2022-01-04 22:15 ` Marc Zyngier
2022-01-05 9:41 ` Eric Auger
2022-01-05 9:41 ` Eric Auger
2022-01-05 9:41 ` Eric Auger
2022-01-06 19:34 ` Marc Zyngier [this message]
2022-01-06 19:34 ` Marc Zyngier
2022-01-06 19:34 ` Marc Zyngier
2022-01-07 17:10 ` Eric Auger
2022-01-07 17:10 ` Eric Auger
2022-01-07 17:10 ` Eric Auger
2021-10-03 16:46 ` [PATCH v2 2/5] hw/arm/virt: Add a control for the the highmem redistributors Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-04 9:44 ` Andrew Jones
2021-10-04 9:44 ` Andrew Jones
2021-10-04 9:44 ` Andrew Jones
2021-10-04 10:14 ` Andrew Jones
2021-10-04 10:14 ` Andrew Jones
2021-10-04 10:14 ` Andrew Jones
2021-10-03 16:46 ` [PATCH v2 3/5] hw/arm/virt: Honor highmem setting when computing the memory map Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-04 9:44 ` Andrew Jones
2021-10-04 9:44 ` Andrew Jones
2021-10-04 9:44 ` Andrew Jones
2021-10-04 12:23 ` Eric Auger
2021-10-04 12:23 ` Eric Auger
2021-10-04 12:23 ` Eric Auger
2021-12-27 16:39 ` Marc Zyngier
2021-12-27 16:39 ` Marc Zyngier
2021-12-27 16:39 ` Marc Zyngier
2021-10-03 16:46 ` [PATCH v2 4/5] hw/arm/virt: Use the PA range to compute " Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-04 10:11 ` Andrew Jones
2021-10-04 10:11 ` Andrew Jones
2021-10-04 10:11 ` Andrew Jones
2021-12-27 20:13 ` Marc Zyngier
2021-12-27 20:13 ` Marc Zyngier
2021-12-27 20:13 ` Marc Zyngier
2021-10-04 10:15 ` Andrew Jones
2021-10-04 10:15 ` Andrew Jones
2021-10-04 10:15 ` Andrew Jones
2021-10-03 16:46 ` [PATCH v2 5/5] hw/arm/virt: Disable highmem devices that don't fit in the PA range Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-03 16:46 ` Marc Zyngier
2021-10-04 10:12 ` Andrew Jones
2021-10-04 10:12 ` Andrew Jones
2021-10-04 10:12 ` Andrew Jones
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=8735m0zmhq.wl-maz@kernel.org \
--to=maz@kernel.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=peter.maydell@linaro.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 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.