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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
