All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 27 Dec 2021 15:53:55 +0000	[thread overview]
Message-ID: <87pmpiyrfw.wl-maz@kernel.org> (raw)
In-Reply-To: <dbe883ca-880e-7f2b-1de7-4b2d3361545d@redhat.com>

Hi Eric,

Picking this up again after a stupidly long time...

On Mon, 04 Oct 2021 13:00:21 +0100,
Eric Auger <eric.auger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 10/3/21 6:46 PM, Marc Zyngier wrote:
> > Currently, the highmem PCIe region is oddly keyed on the highmem
> > attribute instead of highmem_ecam. Move the enablement of this PCIe
> > region over to highmem_ecam.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  hw/arm/virt-acpi-build.c | 10 ++++------
> >  hw/arm/virt.c            |  4 ++--
> >  2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 037cc1fd82..d7bef0e627 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope,
> >  }
> >  
> >  static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> > -                              uint32_t irq, bool use_highmem, bool highmem_ecam,
> > -                              VirtMachineState *vms)
> > +                              uint32_t irq, VirtMachineState *vms)
> >  {
> > -    int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> > +    int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam);
> >      struct GPEXConfig cfg = {
> >          .mmio32 = memmap[VIRT_PCIE_MMIO],
> >          .pio    = memmap[VIRT_PCIE_PIO],
> > @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> >          .bus    = vms->bus,
> >      };
> >  
> > -    if (use_highmem) {
> > +    if (vms->highmem_ecam) {
> highmem_ecam is more restrictive than use_highmem:
> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);
> 
> If I remember correctly there was a problem using highmem ECAM with 32b
> AAVMF FW.
>
> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in
> size") introduced high MMIO PCI region without this constraint.

Then I really don't understand the point of this highmem_ecam. We only
register the highmem version if highmem_ecam is set (see the use of
VIRT_ECAM_ID() to pick the right ECAM window).

So keying this on highmem makes it expose a device that may not be
there the first place since, as you pointed out that highmem_ecam can
be false in cases where highmem is true.

> So to me we should keep vms->highmem here

I really must be missing how this is supposed to work.

	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: Mon, 27 Dec 2021 15:53:55 +0000	[thread overview]
Message-ID: <87pmpiyrfw.wl-maz@kernel.org> (raw)
In-Reply-To: <dbe883ca-880e-7f2b-1de7-4b2d3361545d@redhat.com>

Hi Eric,

Picking this up again after a stupidly long time...

On Mon, 04 Oct 2021 13:00:21 +0100,
Eric Auger <eric.auger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 10/3/21 6:46 PM, Marc Zyngier wrote:
> > Currently, the highmem PCIe region is oddly keyed on the highmem
> > attribute instead of highmem_ecam. Move the enablement of this PCIe
> > region over to highmem_ecam.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  hw/arm/virt-acpi-build.c | 10 ++++------
> >  hw/arm/virt.c            |  4 ++--
> >  2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 037cc1fd82..d7bef0e627 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope,
> >  }
> >  
> >  static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> > -                              uint32_t irq, bool use_highmem, bool highmem_ecam,
> > -                              VirtMachineState *vms)
> > +                              uint32_t irq, VirtMachineState *vms)
> >  {
> > -    int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> > +    int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam);
> >      struct GPEXConfig cfg = {
> >          .mmio32 = memmap[VIRT_PCIE_MMIO],
> >          .pio    = memmap[VIRT_PCIE_PIO],
> > @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> >          .bus    = vms->bus,
> >      };
> >  
> > -    if (use_highmem) {
> > +    if (vms->highmem_ecam) {
> highmem_ecam is more restrictive than use_highmem:
> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);
> 
> If I remember correctly there was a problem using highmem ECAM with 32b
> AAVMF FW.
>
> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in
> size") introduced high MMIO PCI region without this constraint.

Then I really don't understand the point of this highmem_ecam. We only
register the highmem version if highmem_ecam is set (see the use of
VIRT_ECAM_ID() to pick the right ECAM window).

So keying this on highmem makes it expose a device that may not be
there the first place since, as you pointed out that highmem_ecam can
be false in cases where highmem is true.

> So to me we should keep vms->highmem here

I really must be missing how this is supposed to work.

	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: 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: Mon, 27 Dec 2021 15:53:55 +0000	[thread overview]
Message-ID: <87pmpiyrfw.wl-maz@kernel.org> (raw)
In-Reply-To: <dbe883ca-880e-7f2b-1de7-4b2d3361545d@redhat.com>

Hi Eric,

Picking this up again after a stupidly long time...

On Mon, 04 Oct 2021 13:00:21 +0100,
Eric Auger <eric.auger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 10/3/21 6:46 PM, Marc Zyngier wrote:
> > Currently, the highmem PCIe region is oddly keyed on the highmem
> > attribute instead of highmem_ecam. Move the enablement of this PCIe
> > region over to highmem_ecam.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  hw/arm/virt-acpi-build.c | 10 ++++------
> >  hw/arm/virt.c            |  4 ++--
> >  2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 037cc1fd82..d7bef0e627 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope,
> >  }
> >  
> >  static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> > -                              uint32_t irq, bool use_highmem, bool highmem_ecam,
> > -                              VirtMachineState *vms)
> > +                              uint32_t irq, VirtMachineState *vms)
> >  {
> > -    int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> > +    int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam);
> >      struct GPEXConfig cfg = {
> >          .mmio32 = memmap[VIRT_PCIE_MMIO],
> >          .pio    = memmap[VIRT_PCIE_PIO],
> > @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> >          .bus    = vms->bus,
> >      };
> >  
> > -    if (use_highmem) {
> > +    if (vms->highmem_ecam) {
> highmem_ecam is more restrictive than use_highmem:
> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);
> 
> If I remember correctly there was a problem using highmem ECAM with 32b
> AAVMF FW.
>
> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in
> size") introduced high MMIO PCI region without this constraint.

Then I really don't understand the point of this highmem_ecam. We only
register the highmem version if highmem_ecam is set (see the use of
VIRT_ECAM_ID() to pick the right ECAM window).

So keying this on highmem makes it expose a device that may not be
there the first place since, as you pointed out that highmem_ecam can
be false in cases where highmem is true.

> So to me we should keep vms->highmem here

I really must be missing how this is supposed to work.

	M.

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

  reply	other threads:[~2021-12-27 15:54 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 [this message]
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
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=87pmpiyrfw.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --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.