public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "mitchell.augustin via groups.io" <mitchell.augustin=canonical.com@groups.io>
To: "Gerd Hoffmann" <kraxel@redhat.com>, devel@edk2.groups.io
Subject: Re: [edk2-devel] [BUG] Extremely slow boot times with CPU and GPU passthrough and host phys-bits > 40
Date: Tue, 26 Nov 2024 14:27:28 -0800	[thread overview]
Message-ID: <2202.1732660048387996911@groups.io> (raw)
In-Reply-To: <vat4llx23hm5jqzwnakqy23tpuf4j5txoas5quhhccdt26hs3k@odtje24gj3nm>

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

Thanks Gerd,

> When hotplugging devices you might need the 'pref64-reserve=<size>' property for '-device pcie-root-port' to make the bridge window larger.

Double thanks for this - it was exactly what I needed, and I am now able to get hotplug working on a VM where the GPUs weren't attached at boot. (and I can confirm that there is no PCI initialization slowdown when I do it that way, as opposed to attaching at boot time.)

> I think it would be better to just give the PciMmio64Mb config hints higher priority, i.e. if they are present (and don't conflict with installed memory) simply use them as-is

Seems reasonable. Since I was able to get the hotplug approach working as I'd hoped, this may not end up being needed for me (if hotplug is appropriate for my colleague's use case), but I'll keep this in mind.

> But I'd also like to figure what the exact problem is.  Ideally OVMF should just work without requiring manual configuration.  One of the reasons to add the dynamic mmio window was to allow pci devices with large bars to work fine without manual tuning ...

Agreed - I'm hoping to get closer to that answer in this thread ( https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/ ) that I started in the kvm/pci lists. As far as I can tell, PlatformDynamicMMIOWindow isn't doing anything wrong here - it gives me a valid sized window - it just so happens that we were benefiting from the old improperly sized window in a roundabout way as long as our `pci=realloc` workaround was in place in older OVMF versions.

> Can you try to change the manual configuration to be more like the dynamic mmio window configuration, one change at a time (first size, next base, possibly multiple base addresses) and see where exactly it breaks? Does it make a difference if you add a iommu to the virtual machine?
> Hmm.  Looks like the device has more resources on the host. Maybe *that* is the problem.
> What does 'sudo lspci -v' print for the NPU on the host and in the guest?

I'll be out for a few days on holiday, so I'll take a look at these sometime next week.

Thanks again for all the help so far,

Mitchell Augustin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120846): https://edk2.groups.io/g/devel/message/120846
Mute This Topic: https://groups.io/mt/109651206/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3818 bytes --]

  reply	other threads:[~2024-11-26 22:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 16:46 [edk2-devel] [BUG] Extremely slow boot times with CPU and GPU passthrough and host phys-bits > 40 mitchell.augustin via groups.io
2024-11-18 21:14 ` xpahos via groups.io
2024-11-19 22:25   ` mitchell.augustin via groups.io
2024-11-20  9:35     ` xpahos via groups.io
2024-11-20 11:26     ` Gerd Hoffmann via groups.io
2024-11-20 15:20       ` mitchell.augustin via groups.io
2024-11-20 20:00         ` mitchell.augustin via groups.io
2024-11-21 12:32         ` Gerd Hoffmann via groups.io
2024-11-22  0:23           ` mitchell.augustin via groups.io
2024-11-22 10:35             ` Gerd Hoffmann via groups.io
2024-11-22 17:38               ` Brian J. Johnson via groups.io
2024-11-22 22:32               ` mitchell.augustin via groups.io
2024-11-24  2:05                 ` mitchell.augustin via groups.io
2024-11-25 11:47                   ` Gerd Hoffmann via groups.io
2024-11-25 19:58                     ` mitchell.augustin via groups.io
2024-11-26  8:09                       ` Gerd Hoffmann via groups.io
2024-11-26 22:27                         ` mitchell.augustin via groups.io [this message]
2024-12-04 14:56                           ` mitchell.augustin via groups.io
2024-11-25 11:18                 ` Gerd Hoffmann via groups.io
2024-11-18 21:32 ` Ard Biesheuvel via groups.io

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-list 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=2202.1732660048387996911@groups.io \
    --to=devel@edk2.groups.io \
    /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