public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Boeuf, Sebastien" <sebastien.boeuf@intel.com>
To: "kraxel@redhat.com" <kraxel@redhat.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"ardb+tianocore@kernel.org" <ardb+tianocore@kernel.org>
Subject: Re: [OVMF] What would be the best way to make PcdPciMmio64Size dynamic?
Date: Wed, 18 Jan 2023 14:24:10 +0000	[thread overview]
Message-ID: <16ae13baf46750e48e4e461ec31439805c601e49.camel@intel.com> (raw)
In-Reply-To: <20230117143818.oy5fer3sgt23hljh@sirius.home.kraxel.org>

On Tue, 2023-01-17 at 15:38 +0100, kraxel@redhat.com wrote:
> On Tue, Jan 17, 2023 at 02:10:08PM +0000, Boeuf, Sebastien wrote:
> > Hi,
> > 
> > Looking at the hardcoded limitation provided by PcdPciMmio64Size
> > (32GiB), I was wondering what would be the best approach to make
> > this a
> > bit more dynamic?
> > 
> > I know that for QEMU, the fw_cfg mechanism can be used to override
> > the
> > value of PcdPciMmio64Size, but this isn't something Cloud
> > Hypervisor or
> > other VMMs can implement given they don't support fw_cfg at all.
> > 
> > Would it be acceptable to dynamically compute PcdPciMmio64Size from
> > the
> > physical address space? Given the reason why PcdPciMmio64Size can't
> > be
> > increased is to make sure it can support host with small address
> > space
> > (such as 36 bits), we could introduce a very simple function that
> > would
> > determine the available address space and consider PcdPciMmio64Size
> > being half the size.
> 
> Sure, check master branch, the code is already there.  Should just be
> a
> matter of wiring up the function calls for cloundhv, and you can
> probably call PlatformAddressWidthFromCpuid() with QemuQuirk = false
> unconditionally.

Ah thank you for the pointer, the code is exactly what I had in mind.
I sent a patch to disable the QemuQuirk in case of Cloud Hypervisor,
which then result in the proper address space size to be returned, and
therefore the 64-bit MMIO window to be computed dynamically!

Thanks,
Sebastien

> 
> take care,
>   Gerd
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

      reply	other threads:[~2023-01-18 14:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 14:10 [OVMF] What would be the best way to make PcdPciMmio64Size dynamic? Boeuf, Sebastien
2023-01-17 14:38 ` Gerd Hoffmann
2023-01-18 14:24   ` Boeuf, Sebastien [this message]

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=16ae13baf46750e48e4e461ec31439805c601e49.camel@intel.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