From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
Neowutran <xen@neowutran.ovh>
Subject: Re: [PATCH] hvmloader/PCI: skip huge BARs in certain calculations
Date: Tue, 5 Mar 2024 10:31:48 +0100 [thread overview]
Message-ID: <ZebmhBHpFasxFfiW@macbook> (raw)
In-Reply-To: <090d572c-5196-46b2-9d6b-741b7cb66d97@suse.com>
On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> the lower 2Gb range and the top of the higher 2Gb range have special
> purpose. Don't even have them influence whether to (perhaps) relocate
> low RAM.
>
> Reported-by: Neowutran <xen@neowutran.ovh>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent
> to similarly avoid low RAM relocation in the first place. Yet accounting
> for things differently depending on how many large BARs there are would
> require more intrusive code changes.
>
> That said, I'm open to further lowering of the threshold. That'll
> require different justification then, though.
>
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -33,6 +33,13 @@ uint32_t pci_mem_start = HVM_BELOW_4G_MM
> const uint32_t pci_mem_end = RESERVED_MEMBASE;
> uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>
> +/*
> + * BARs larger than this value are put in 64-bit space unconditionally. That
> + * is, such BARs also don't play into the determination of how big the lowmem
> + * MMIO hole needs to be.
> + */
> +#define HUGE_BAR_THRESH GB(1)
I would maybe name this `BAR_RELOCATE_THRESH, `HUGE_BAR` is too
generic IMO.
And also use 256Mb instead of 1GB, but just having a limit is good
enough, we can further tune it afterwards.
> +
> enum virtual_vga virtual_vga = VGA_none;
> unsigned long igd_opregion_pgbase = 0;
>
> @@ -286,9 +293,11 @@ void pci_setup(void)
> bars[i].bar_reg = bar_reg;
> bars[i].bar_sz = bar_sz;
>
> - if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> - PCI_BASE_ADDRESS_SPACE_MEMORY) ||
> - (bar_reg == PCI_ROM_ADDRESS) )
> + if ( is_64bar && bar_sz > HUGE_BAR_THRESH )
> + bar64_relocate = 1;
> + else if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> + PCI_BASE_ADDRESS_SPACE_MEMORY) ||
> + (bar_reg == PCI_ROM_ADDRESS) )
> mmio_total += bar_sz;
>
> nr_bars++;
> @@ -367,7 +376,7 @@ void pci_setup(void)
> pci_mem_start = hvm_info->low_mem_pgend << PAGE_SHIFT;
> }
>
> - if ( mmio_total > (pci_mem_end - pci_mem_start) )
> + if ( mmio_total > (pci_mem_end - pci_mem_start) || bar64_relocate )
> {
> printf("Low MMIO hole not large enough for all devices,"
> " relocating some BARs to 64-bit\n");
> @@ -446,8 +455,9 @@ void pci_setup(void)
> * the code here assumes it to be.)
> * Should either of those two conditions change, this code will break.
> */
> - using_64bar = bars[i].is_64bar && bar64_relocate
> - && (mmio_total > (mem_resource.max - mem_resource.base));
> + using_64bar = bars[i].is_64bar && bar64_relocate &&
> + (mmio_total > (mem_resource.max - mem_resource.base) ||
> + bar_sz > HUGE_BAR_THRESH);
There's a comment above this that starts with:
"Relocate to high memory if the total amount of MMIO needed is more
than the low MMIO available."
I would slightly reword it to:
"Relocate to high memory if the total amount of MMIO needed is more
than the low MMIO available or BARs bigger that HUGE_BAR_THRESH are
present."
Thanks, Roger.
next prev parent reply other threads:[~2024-03-05 9:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 7:32 [PATCH] hvmloader/PCI: skip huge BARs in certain calculations Jan Beulich
2024-03-04 10:02 ` Roger Pau Monné
2024-03-04 13:25 ` Jan Beulich
2024-03-05 9:25 ` Roger Pau Monné
2024-03-05 9:56 ` Jan Beulich
2024-03-04 11:42 ` Alejandro Vallejo
2024-03-05 9:31 ` Roger Pau Monné [this message]
2024-03-05 10:05 ` Jan Beulich
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=ZebmhBHpFasxFfiW@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
--cc=xen@neowutran.ovh \
/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.