From: "Vivek Kasireddy" <vivek.kasireddy@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"lersek@redhat.com" <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>, "Kim, Dongwon" <dongwon.kim@intel.com>
Subject: Re: [edk2-devel] [PATCH v1] OvmfPkg/PlatformInitLib: Don't override user specified PciMmio64Size
Date: Tue, 7 Nov 2023 05:42:09 +0000 [thread overview]
Message-ID: <IA0PR11MB71859F1A439E5582EBFE5053F8A9A@IA0PR11MB7185.namprd11.prod.outlook.com> (raw)
In-Reply-To: <d37eglm5duzzbywi6jfkrmyb7q25x4z6ng3l23vfwdaxn7t3mc@dragfbvkhwak>
Hi Gerd,
>
> 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.
Right, the crux of the problem is indeed the placement of the window
and not the size. Given this, do you see any problem if the mmio window
were to be placed at the lower end of the address space? Or, do you think
ensuring that PhysMemAddressWidth = <IOMMU address width>
automatically via Qemu/OVMF like Laszlo suggested is a better solution
for this problem?
Thanks,
Vivek
>
> take care,
> Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110805): https://edk2.groups.io/g/devel/message/110805
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]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-11-07 5:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 5:15 [edk2-devel] [PATCH v1] OvmfPkg/PlatformInitLib: Don't override user specified PciMmio64Size Vivek Kasireddy
2023-11-03 13:15 ` Laszlo Ersek
2023-11-03 14:07 ` Laszlo Ersek
2023-11-06 11:47 ` Gerd Hoffmann
2023-11-07 5:42 ` Vivek Kasireddy [this message]
2023-11-07 10:26 ` Gerd Hoffmann
2023-11-08 6:24 ` Vivek Kasireddy
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=IA0PR11MB71859F1A439E5582EBFE5053F8A9A@IA0PR11MB7185.namprd11.prod.outlook.com \
--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