Re: [edk2-devel] [PATCH v1] OvmfPkg/PlatformInitLib: Don't override user specified PciMmio64Size

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> > I agree that the proposed patch can function as a stop-gap, but the QEMU
> > command line hack is already a stop-gap. And for the long term, this
> > patch is not good enough. We should enhance the dynamic sizing, now that
> > Gerd has put it into place.
> 
> ... I do agree however that the current behavior is strange -- the user
> specifies an explicit fw_cfg knob for OVMF, and OVMF ignores it (for
> whatever reason).
> 
> I'd like to know what Gerd thinks of this.

The current code effectively considers the user-specified PciMmio64Size
as a lower limit, it will never be smaller but might be larger in case
OVMF figures it has enough space.

Being more strict here and use the user-specified PciMmio64Size as-is no
matter what is fine with me.

The independent but related question is where the window should be
placed in case we have a valid vcpu address space size and PciMmio64Size
specified by the user.

> (b) there were a promise to enhance QEMU and OVMF as I suggest above.

Fully agree.  We should explicitly communicate requirements (in this
case: iommu address space size) instead of depending on side effects
of unrelated config options.

Strictly speaking you don't care that much about the size of the mmio
window, but where it gets placed.  Moving it to the end of the vcpu
address space is what breaks your use case in case the iommu address
space happens to be too small for that.

take care,
  Gerd



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